A08:2025 – Software and Data Integrity Failures
Overview
Software and Data Integrity Failures focus on situations where applications trust data, code, or updates that should not be trusted, or fail to verify that critical elements have not been altered. In the OWASP Top 10:2025, this category highlights how integrity — not just confidentiality — is a foundational security requirement that is frequently overlooked.
While cryptography (A04) is about protecting data from being read or tampered with, A08 is about detecting and preventing unauthorized modification of:
software components
updates and plugins
configuration files
serialized data
messages exchanged between systems
From an attacker’s perspective, integrity failures are powerful because they allow:
silent manipulation instead of loud exploitation
persistence across restarts and deployments
indirect compromise through trusted mechanisms
abuse of update and trust chains
Integrity Is About Trust
Integrity failures always involve misplaced trust.
Applications trust that:
code has not been modified
updates are legitimate
data has not been tampered with
messages come from a trusted source
serialized objects are safe to deserialize
When this trust is not explicitly verified, attackers step in.
Unlike injection or authentication attacks, integrity failures often occur outside normal request/response flows, making them harder to detect and easier to persist.
Software Integrity vs Data Integrity
A08 intentionally groups two related but distinct concepts:
Software Integrity Ensuring that code, binaries, dependencies, plugins, and updates have not been altered maliciously.
Data Integrity Ensuring that data has not been modified, forged, replayed, or injected in ways that violate trust assumptions.
Failures in either area can completely undermine an application’s security model.
Why Integrity Failures Are So Dangerous
Integrity failures are especially dangerous because they:
often do not break functionality
rarely generate obvious errors
operate within trusted execution paths
survive redeployments
bypass perimeter controls
From an attacker’s point of view, compromising integrity means the system will work for the attacker, not against them.
Common Sources of Integrity Failure
In modern applications, integrity failures often arise from:
unsigned or unverified software updates
insecure deserialization
trusting client-controlled state
missing message authentication
weak or missing checksums
lack of verification in CI/CD pipelines
plugins or extensions loaded without validation
Many of these issues are introduced for convenience or performance, not because developers intentionally weaken security.
Integrity Failures Are Often Supply-Chain Adjacent
A08 overlaps conceptually with A03 – Software Supply Chain Failures, but focuses more narrowly on verification and enforcement.
Where A03 asks:
“What if the supply chain is compromised?”
A08 asks:
“What happens if compromised components are trusted without verification?”
In many real-world attacks, supply chain compromise is only successful because integrity checks are missing or weak.
Insecure Deserialization as a Core Example
One of the most well-known integrity failures is insecure deserialization.
In this scenario:
the application accepts serialized objects
trusts their structure and content
reconstructs them into live objects
If integrity is not enforced, attackers can:
modify object state
inject unexpected behavior
trigger logic abuse
achieve code execution
This is a textbook example of trusting data that should never be trusted.
Integrity vs Authentication and Authorization
Integrity failures differ from authentication failures (A07) and access control issues (A01):
Authentication answers: Who are you?
Authorization answers: What can you do?
Integrity answers: Can I trust this data or code at all?
An application may authenticate a user correctly and still be completely compromised if it trusts manipulated data or software components.
Attacker Perspective
From an offensive mindset, integrity failures are ideal because:
attacks can be stealthy
exploitation often looks like normal behavior
compromised components remain trusted
detection is difficult
remediation is slow
Attackers are not breaking the system — they are becoming part of it.
What Are Software and Data Integrity Failures?
Software and Data Integrity Failures occur when an application fails to ensure that code, data, or messages have not been modified in an unauthorized way. In these situations, the application accepts and processes information that it assumes to be trustworthy, even though that trust is not enforced or verified.
At a fundamental level, integrity failures happen when the system does not answer — or cannot reliably answer — the question:
“Has this been altered since it was created or approved?”
If the system cannot confidently answer that question, integrity has failed.
Integrity Is About Tamper Detection, Not Secrecy
A common misconception is equating integrity with confidentiality.
Confidentiality ensures data cannot be read by unauthorized parties.
Integrity ensures data cannot be modified without detection.
A system may encrypt data perfectly and still suffer integrity failures if attackers can:
alter encrypted payloads
replay messages
inject modified objects
replace trusted components
Encryption without integrity checks is incomplete protection.
Trust Without Verification Is the Root Cause
Most integrity failures originate from implicit trust.
Applications trust that:
serialized objects are unchanged
configuration files are intact
updates are legitimate
messages have not been tampered with
client-provided state is accurate
When this trust is not backed by:
signatures
MACs
checksums
strict validation
secure update mechanisms
Attackers can manipulate data or code undetected.
Software Integrity Failures
Software integrity failures involve untrusted or modified code being executed as if it were legitimate.
Examples include:
unsigned plugins or extensions
unverified updates
tampered binaries
compromised dependencies
modified scripts or templates
From an attacker’s perspective, software integrity failures are valuable because once malicious code is trusted, it executes with the same privileges as legitimate code.
Data Integrity Failures
Data integrity failures involve tampered or forged data being accepted and processed.
Examples include:
insecure deserialization
missing message authentication
client-controlled state trusted server-side
replayable requests or tokens
altered configuration data
These failures allow attackers to:
change application behavior
bypass logic checks
escalate privileges
persist malicious state
Insecure Deserialization as an Integrity Failure
Insecure deserialization is a classic integrity failure.
The application:
receives serialized data
assumes it is well-formed and trustworthy
reconstructs objects or state
executes logic based on that state
If attackers can modify serialized data, they control:
object attributes
application state
execution flow
The failure is not deserialization itself — it is trusting the integrity of the serialized input.
Integrity Failures Are Often Silent
One of the most dangerous aspects of integrity failures is that they often:
do not cause errors
do not break functionality
look like valid input or updates
persist across sessions
The system behaves “normally,” while attackers manipulate trusted components behind the scenes.
Integrity Failures Enable Other Attacks
Integrity failures frequently act as enablers:
malicious updates enable persistence
tampered data enables logic abuse
forged messages enable impersonation
modified state bypasses access control
They often sit below other OWASP categories, quietly undermining them.
Attacker Perspective
From an offensive standpoint, integrity failures mean:
“I don’t need to break the system — I just need the system to trust me.”
Once that trust is established, the attacker operates inside the security boundary.
Common Software and Data Integrity Failure Scenarios
Software and data integrity failures tend to appear in recurring, recognizable patterns. They are rarely accidental edge cases; instead, they emerge when systems are designed to consume, trust, and execute data or code without verifying that it has not been altered.
Below are the most common integrity failure scenarios observed during real-world offensive testing.
Insecure Deserialization
Insecure deserialization occurs when an application deserializes data from an untrusted source without verifying its integrity or structure.
This typically happens when:
serialized objects are accepted from the client
integrity checks (signatures, MACs) are missing
object state is trusted implicitly
deserialization triggers logic automatically
Attackers exploit this by modifying serialized data to:
change object attributes
inject unexpected values
bypass business logic
trigger code execution in some environments
The vulnerability is not deserialization itself — it is trusting the serialized input.
Unsigned or Unverified Software Updates
Applications that load updates, plugins, or extensions without verifying authenticity are vulnerable to integrity compromise.
Common failure patterns include:
updates downloaded over insecure channels
missing digital signatures
lack of checksum validation
trusting update servers implicitly
Attackers can replace legitimate updates with malicious ones, gaining:
persistent execution
trusted code paths
long-term access
This is especially dangerous because malicious code appears legitimate.
Client-Controlled State Trusted Server-Side
Some applications rely on client-side data to maintain state, such as:
serialized session objects
hidden form fields
encoded or encrypted values
client-generated identifiers
If integrity is not enforced, attackers can tamper with this state to:
modify roles or permissions
skip workflow steps
alter prices or quantities
manipulate application logic
Encryption without integrity validation does not prevent tampering.
Missing Message Authentication
Applications that exchange messages between components without message authentication are vulnerable to integrity failures.
Examples include:
APIs without request signing
webhooks without verification
internal service calls without MACs
queue messages without integrity checks
Attackers can:
forge requests
replay messages
modify payloads
impersonate trusted services
If a message is not authenticated, it cannot be trusted.
Replayable Requests and Tokens
Integrity failures also appear when requests or tokens can be reused without detection.
Common examples:
lack of nonces or timestamps
predictable request identifiers
idempotent endpoints without safeguards
tokens not bound to context
Attackers replay valid messages to:
repeat actions
bypass one-time checks
trigger unintended behavior
Replay attacks often look like normal traffic.
Tampered Configuration and Metadata
Applications often load configuration or metadata dynamically.
Integrity failures occur when:
configuration files are writable
metadata is loaded without validation
environment variables are trusted blindly
configuration changes are not monitored
Attackers modify configuration to:
weaken security controls
redirect execution
expose sensitive data
Configuration integrity is often overlooked but critical.
Trusting Third-Party Inputs and Webhooks
Third-party integrations frequently introduce integrity risks.
Common issues include:
accepting webhooks without verification
trusting callback parameters
missing signature validation
weak shared secrets
Attackers forge or manipulate third-party messages to trigger actions inside the application.
Weak or Missing Integrity Checks in CI/CD
Build and deployment pipelines are also integrity-sensitive.
Failures include:
unsigned build artifacts
missing checksum validation
insecure artifact storage
lack of immutability
Attackers who compromise integrity here affect everything downstream.
Why These Scenarios Matter
These scenarios show that integrity failures:
exploit trust rather than bugs
persist across sessions and deployments
operate silently
undermine other security controls
Once integrity is lost, everything built on top of it becomes suspect.
Testing Perspective (Offensive Mindset)
Testing for software and data integrity failures requires a shift in mindset. Instead of focusing on inputs and outputs, attackers focus on what the application trusts implicitly and whether that trust can be abused.
From an offensive perspective, integrity testing is about answering one question:
“What does this system accept as genuine without verifying?”
If something is trusted without verification, it becomes an attack surface.
Think in Terms of Trust Chains
Integrity failures almost always exist within a trust chain.
Attackers map:
where data is created
how it is transported
how it is stored
how it is consumed
what checks (if any) exist along the way
Any break or missing link in that chain allows tampering.
Assume All External Input Can Be Modified
From an attacker’s point of view, anything that:
comes from the client
crosses a network boundary
is loaded from disk
is pulled from a third party
is generated outside the current execution context
must be assumed modifiable.
If the application does not explicitly verify integrity, attackers assume modification is possible.
Focus on Serialized and Structured Data
Serialized data is a primary target because it often:
represents internal state
controls logic flow
is assumed to be “safe”
is deserialized automatically
Attackers test whether:
serialized objects can be altered
integrity checks exist
unexpected fields are accepted
state transitions can be manipulated
Deserialization without integrity enforcement is always suspicious.
Test Message Authenticity, Not Just Transport Security
Encryption protects confidentiality, not integrity by itself.
Attackers test whether:
messages are signed
payloads are authenticated
sources are verified
replay protection exists
APIs, webhooks, queues, and internal services are all prime targets.
If a message is accepted because it “looks right,” it can likely be forged.
Abuse Legitimate Mechanisms
Integrity failures are often exploited by abusing legitimate mechanisms:
update systems
plugin loaders
configuration reloads
synchronization processes
background jobs
Attackers prefer these paths because:
they run with high privileges
they are trusted by design
activity blends into normal operations
Look for Persistence Opportunities
Integrity failures often provide persistence.
Attackers look for:
configuration changes that survive restarts
tampered state stored in databases
malicious plugins or extensions
modified artifacts reused across deployments
Persistence without re-exploitation is a major red flag.
Replay and Reuse Everything
Attackers routinely test replay:
resend captured requests
reuse tokens
repeat state-changing actions
replay signed-but-unbounded messages
If replay is possible, integrity guarantees are incomplete.
Assume Detection Is Weak
Integrity abuse often produces:
no errors
no crashes
no obvious anomalies
Attackers assume:
integrity failures are not logged
changes are not monitored
tampering blends in with valid behavior
This assumption is frequently correct.
Integrity Failures Chain Easily
From an offensive standpoint, integrity failures rarely stand alone.
They often enable:
access control bypass
authentication abuse
privilege escalation
supply chain compromise
Attackers chain integrity abuse with other weaknesses to amplify impact.
Final Offensive Principle
Integrity testing is about breaking trust without breaking functionality.
If the application assumes:
“this data hasn’t changed”
“this update is legitimate”
“this message came from us”
“this state is safe to trust”
And that assumption is not enforced cryptographically or logically — that assumption is the vulnerability.
Hands-on Testing Checklist – Software and Data Integrity Failures (A08:2025)
This checklist is intended for active offensive testing focused on integrity guarantees. It helps validate whether software, data, and messages are trusted without proper verification.
The core principle is:
If integrity is assumed instead of enforced, it can be broken.
Final Attacker Mindset
Integrity failures are about becoming trusted without earning trust.
If the system assumes:
“this data hasn’t changed”
“this update is legitimate”
“this message came from us”
“this state is safe”
And that assumption is not verified — the attacker will make it false.
Last updated