OWASP A08
Testing for Software and Data Integrity Failures
This category is about trusting data or code whose origin was never verified — deserialised objects, unsigned updates, pipeline artifacts and values the client was allowed to decide.
- Covers deserialisation and pipeline trust together
- Tests client-supplied state accepted without verification
- Includes update and artifact signing review
What integrity failures looks like in a real application
A checkout flow stores the cart in a signed cookie to avoid a database round trip. The signature is verified, so tampering fails. The signing key is the framework's default from a tutorial, published in documentation and present in thousands of repositories. The integrity control exists, is implemented correctly, and provides nothing.
The integrity failures variants we test for
- Insecure deserialisation of user-controlled data in formats that can instantiate arbitrary types, frequently reaching code execution
- Signed data with weak or default keys, where the signature is verifiable by anyone
- Client-decided state — prices, quantities, discounts, entitlements, role and tenant carried in a request and trusted on arrival
- Unsigned or unverified updates, including auto-update paths and downloaded plugins
- Pipeline trust: who can modify build definitions, inject steps, or publish artifacts without review
- Dependency substitution risks such as name confusion between internal and public registries
- Third-party scripts loaded without integrity attributes, where the provider can change what executes in your users' browsers
- Webhook and callback authenticity, where a payload claiming to be from a payment provider is accepted without signature verification
How we test for integrity failures
We look for places where the application accepts something it did not produce and treats it as trustworthy. Any opaque or encoded value moving through the client is a candidate: we decode it, attempt modification, and determine whether integrity is verified at all and if so with what key.
Webhook endpoints get specific attention, because they are frequently exposed, frequently unauthenticated, and frequently drive money movement or entitlement changes. Forging a provider callback is one of the higher-impact findings available in a typical platform.
Where pipeline configuration is in scope, we review who can change what gets built and shipped, since a control on the application matters little if the artifact can be altered on the way to production.
How integrity failures gets fixed
- Never deserialise user-controlled data into arbitrary types — use a data-only format and map fields explicitly
- Keep authoritative state server-side; if the client must carry it, sign with a strong per-environment key and re-validate the business rules anyway
- Verify webhook signatures against the provider's published scheme before acting on the payload
- Pin third-party scripts with integrity attributes, or self-host them
- Require review on pipeline definitions and sign published artifacts
- Resolve internal package names from a private registry that cannot be shadowed publicly
Common questions
Is insecure deserialisation still relevant?
Yes, though it appears differently now. Direct object deserialisation of user input is less common in newly written code, but it persists in caching layers, session storage, message queues and older services, and it remains one of the more reliable routes from a single request to code execution when present.
Our cart data is signed. Is that enough?
Only if the key is strong, environment-specific and secret, and only if the server re-validates the business rules regardless. Signing proves the value has not been altered; it does not prove the value was ever correct. We check both the cryptographic strength and whether the server would notice an internally consistent but commercially absurd payload.
Do you test our CI/CD pipeline?
If you include it in scope, yes — permissions on build definitions, who can publish artifacts, secret exposure to build steps and dependency resolution. It is worth including, because pipeline compromise bypasses every control in the application it builds.
How do we verify webhooks from payment providers?
Verify the signature the provider publishes, against the raw request body before any parsing or re-serialisation, using a constant-time comparison. Then check the event is not a replay and reconcile against the provider's API before acting on anything financial. Accepting a webhook because it arrived at the expected URL is equivalent to having no authentication on it.
Should we self-host third-party scripts?
Where practical, yes, because it converts an ongoing trust relationship into a versioned dependency you control. Where you cannot, pin the resource with a subresource integrity hash so the browser refuses altered content. The risk of a hosted script is not that the provider is malicious but that anything they ship executes with full access to your users' sessions.
What is the practical risk of unsigned build artifacts?
That a compromise anywhere in your pipeline reaches production without needing to touch your source code. Signing artifacts and verifying signatures at deploy time means an altered build fails rather than ships. It matters most for teams with many contributors or many pipeline integrations, because each one is a place where a build step can be added.
Do you review who can change our deployment pipeline?
If it is in scope, yes, and we recommend including it. Application controls are only as strong as the process that builds and ships the application, so we look at who can modify build definitions, who can publish, whether changes are reviewed, and which secrets are exposed to build steps. Pipeline access frequently turns out to be broader than teams expect.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.