Software or data integrity failures: trusting what was never checked

Figures are from the A08:2025 page of the OWASP Top 10.

OWASP gives four examples.

• Code from untrusted sources. Plugins, libraries or modules taken from repositories or CDNs the application has no reason to trust.
• Pipelines that do not verify. Build and deployment steps that pull artifacts without checking their signatures.
• Updates applied unchecked. Auto-update features that download and install without verifying integrity.
• Insecure deserialization. Serialized data that an attacker can see and modify is trusted as it arrives.

Serialization turns an object in memory into bytes or text so it can be stored or sent; deserialization rebuilds the object on the other side. Some formats, such as the native serialization of Java and PHP, record which class each object belongs to, and rebuilding an object runs code from that class.

That is the danger. If an attacker can change the data before it is deserialized, they choose which classes are rebuilt and with what values. Chaining classes that already exist in the application and its libraries can lead to running commands, without the attacker uploading any code. This is CWE-502, deserialization of untrusted data.

The safer pattern is to exchange plain data, such as JSON parsed into simple values, and build objects from it in your own code. Where native serialization cannot be avoided, sign the data and check the signature before deserializing, and restrict which classes may be rebuilt. The OWASP Deserialization Cheat Sheet gives the details for each language.

Three of the four examples never touch the request path. A malicious package enters at build time, an unsigned update at install time, a compromised script from a third-party host in the visitor's browser.

Insecure deserialization is the exception. In OWASP's scenario, an application passes serialized user state between its front end and its services; an attacker recognises the signature of Java serialization in the data and replaces it with an object that runs code when the server deserializes it. That object arrives in a request, and serialization formats have recognisable markers.

• It can refuse known serialized payloads. Markers of serialization formats in parameters or bodies are distinctive, and rule sets describe them.
• It cannot verify a signature. Whether a package, an artifact or an update is genuine is checked where it is installed, not where requests arrive.
• It cannot see the visitor's browser. A script loaded from a third-party host runs in the visitor's browser, outside any filter in front of your origin.
• It cannot repair the trust decision. If the application deserializes whatever it receives, the next unrecognised payload still runs.

• Verify signatures. Digital signatures or equivalent checks confirm that software or data comes from the expected source unaltered.
• Use trusted repositories. Dependencies come from known registries, and higher-risk environments use an internal, vetted mirror.
• Review changes. Code and configuration changes pass a review before they reach the pipeline.
• Protect the pipeline. Build and deployment systems are segregated, configured carefully and access-controlled.
• Do not trust serialized data from clients. Unless it carries an integrity check or signature that detects tampering or replay.

In the OWASP Core Rule Set, REQUEST-944 covers Java attacks, including deserialization, and REQUEST-933 covers PHP attacks, including object injection; see the rule files.

A script loaded from someone else's host can change without notice, and the change runs in every visitor's browser. Subresource Integrity lets the page state the expected hash of the file in an integrity attribute; the browser refuses to run a file that does not match.

It suits files that are fixed by version, such as a library at a pinned release, and not scripts that change by design, such as analytics tags. Limiting which hosts may supply scripts at all is the job of Content Security Policy.