Software or Data Integrity Failures: Checking What We Trust

Software or Data Integrity Failures is the eighth category in the OWASP Top 10:2025. The question I am using for this part of my PWPA notes is: what evidence allows the application to trust what it has received?

A downloaded update, a build artifact, and a value returned by a browser may all have the expected format. The application still needs to decide whether each item comes from an acceptable source and whether it has been changed.

How this connects to the software supply chain

The earlier Software Supply Chain Failures post looked at the wider process that produces and delivers an application: dependencies, repositories, build systems, people, and permissions.

A08 focuses more closely on the software and data being accepted within that process and by the application itself. There is overlap. A protected build pipeline and verification of its output address related parts of the same path.

OWASP's A08 overview includes updates installed without sufficient verification and untrusted serialized objects being accepted by an application.

An update needs more than a familiar filename

Imagine an application that downloads an update and installs it because the file has the expected name.

That name says little about who produced the file or what happened to it before installation. The update process needs a verification mechanism tied to a trusted source, along with a safe response when verification fails.

A digital signature can help establish that an artifact was signed with a particular key and has not changed since signing. The application must also know which signing keys it should trust.

A valid signature does not establish that the code is free of vulnerabilities or malicious behavior. It answers a narrower question about the artifact and its signer. Review, build security, and protection of signing keys still matter.

A checksum needs a trustworthy reference

A cryptographic hash can show whether a file matches an expected value. The source of that expected value matters.

If someone can replace both the download and the checksum displayed beside it, comparing them does not independently establish the publisher's identity. The verification process needs to protect the reference value or use an authenticated mechanism, such as a properly verified signature.

This is why “we checked a hash” leads to another question in my notes: where did the trusted value come from?

Encoded data remains input

Serialization turns data or objects into a form that can be stored or transmitted. Deserialization reconstructs them.

Suppose a hypothetical application sends account-related state to a browser and later accepts the returned state as authoritative. Encoding that state does not stop the browser's user from changing it. The server still needs to validate what it accepts and enforce its own security decisions.

Some deserialization mechanisms can do much more than read simple values, including constructing object types with dangerous behavior. The OWASP Deserialization Cheat Sheet recommends safer data formats and avoiding unsafe handling of untrusted serialized objects.

Even a simple data format needs validation. A value can be well-formed and still describe a role, price, or account state that the sender has no authority to choose.

Integrity has a scope

Encryption alone does not necessarily detect tampering. An integrity mechanism also does not automatically stop a previously valid message from being replayed. Freshness, expiry, and replay handling need to be considered separately where they matter. The OWASP Cryptographic Storage Cheat Sheet provides more detail on authenticated encryption and the limits of the protection it provides.

For my notes, that means being specific about each check:

Which source is trusted to provide this item?
What prevents unauthorized changes?
Is verification completed before the item is used?
What happens if the check fails?
Could an old but valid item be accepted again?
What further validation and authorization are needed?

My takeaway

This category makes me look more closely at the point where received software or data becomes trusted. The check needs to support the particular trust decision the application is making.

Next is Security Logging & Alerting Failures, where the focus moves to recognizing and responding to security-relevant events.

Sources and further reading