A08:2025 - Software or Data Integrity Failures

Software or Data Integrity Failures holds position eight in the OWASP Top 10 for 2025, unchanged from the 2021 edition where it was first introduced. This category absorbed "Insecure Deserialization" (A08:2017) and broadened its scope to cover any scenario where code or data is used without verifying its integrity, from deserializing untrusted objects to loading external scripts without integrity checks.

Overview

Modern applications rely on code and data from numerous sources: third-party libraries fetched from CDNs, serialized objects exchanged between services, CI/CD pipelines that build and deploy code, and auto-update mechanisms that pull new versions at runtime. When any of these sources is consumed without verifying integrity, an attacker can inject malicious code or data that the application trusts implicitly.

Insecure deserialization remains the most dangerous subset of this category because it frequently leads to remote code execution. However, the broader framing in 2025 recognizes that integrity failures extend well beyond deserialization to encompass any trust assumption about code or data provenance. Radar focuses on the code-level patterns that indicate integrity failures, particularly insecure deserialization across multiple language ecosystems and missing integrity verification on externally loaded resources.

What Radar Detects

• Insecure deserialization in C#/.NET.**Use of BinaryFormatter.Deserialize(), SoapFormatter, NetDataContractSerializer, LosFormatter, and JSON.NET configured with TypeNameHandling.All, TypeNameHandling.Auto, or TypeNameHandling.Objects, all of which allow arbitrary type instantiation from untrusted input.

• Insecure deserialization in Python.**Calls to pickle.loads(), pickle.load(), yaml.load() without SafeLoader, and marshal.loads() on data from untrusted sources, enabling arbitrary code execution during deserialization.

• Insecure deserialization in Java.**Use of ObjectInputStream.readObject() on untrusted input, including patterns that expose applications to Commons Collections gadget chains and similar exploitation techniques.

• Insecure deserialization in PHP.**Calls to unserialize() with user-controlled data, enabling object injection attacks through PHP magic methods (__wakeup, __destruct, __toString).

• Insecure deserialization in Ruby.**Use of Marshal.load() and YAML.load() (before Ruby versions that default to safe loading) on untrusted input, allowing arbitrary object instantiation.

• Prototype pollution (JavaScript).**Patterns where user-controlled data is merged into Object.prototype through unsafe deep merge, deep clone, or object extension utilities, allowing attackers to inject properties that affect all objects in the application.

• Unsigned or unverified external code.**Loading scripts and stylesheets from CDNs or external sources without Subresource Integrity (SRI) hashes, allowing compromised or tampered external resources to execute in the application context.

Related CWEs

CWE-502 (Deserialization of Untrusted Data), CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes).

See the CWE Reference for details.

Prevention

• Never deserialize data from untrusted sources using formats that support object instantiation. Use data-only serialization formats such as JSON or MessagePack instead.
• When deserialization with type information is unavoidable, enforce strict type allowlists and reject any types not explicitly permitted.
• Apply digital signatures to serialized data and verify those signatures before deserialization to ensure the data has not been tampered with.
• In JavaScript, use Object.create(null) or Map for dictionary-like structures instead of plain objects to prevent prototype pollution through property injection.
• Add Subresource Integrity (SRI) hashes to all <script> and <link> tags that load resources from external CDNs or third-party origins.
• Verify the integrity of your CI/CD pipeline by signing build artifacts, using reproducible builds, and validating checksums at each stage of the deployment process.
• Implement Content Security Policy (CSP) headers to restrict which external origins can serve scripts and styles to your application.
• Review auto-update mechanisms to ensure they verify digital signatures on downloaded packages before applying updates.

Next Steps