Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
  1. Support Center
  2. Issue Definitions
  3. Serialized object in HTTP message

Serialized object in HTTP message

Description: Serialized object in HTTP message

Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:

  • Any sensitive data contained within the object can be viewed by the user.
  • An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.
  • An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.

Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.

Remediation: Serialized object in HTTP message

The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.

Vulnerability classifications

Typical severity


Type index


Burp Scanner

This issue - and many more like it - can be found using our web vulnerability scanner

Read more

Get Burp

Scan your web application from just $399.00

Find out more