🛠️ A Broken Piece Can Bring Down the Whole! OWASP #8, Software and Data Integrity Failures

Oct 31, 2026

—

Hello! 👋 Welcome to the OWASP Top 10 Conquest Series. Today, we’ll explore A08:2021-Software and Data Integrity Failures, a new entry in 2021 that emphasizes its critical importance.

What if someone secretly erased or altered text on an important document? Or what if a program file you downloaded was tampered with midway and turned into malware? 😱 ‘Integrity’ in this context means that data or software remains in its original state, without being unintentionally changed or corrupted. Software and data integrity failures occur precisely when this core ‘trust’ is broken. Let’s examine together how the trust in our systems can be compromised! 🕵️‍♀️

🤔 Software and Data Integrity Failures? What are they?

“Any issue where software or data does not remain in its originally intended, untampered state.” 📉

Software and Data Integrity Failures are vulnerabilities that occur when core elements of an application, such as code, data, and configuration files, are introduced from untrusted sources or are at risk of being tampered with or corrupted during transmission or storage.

This problem can arise at various stages of the Software Development Life Cycle (SDLC).

Code Development and Build Process: Libraries and frameworks used by developers can be tampered with malicious code.
Deployment and Updates: Software update files can be altered midway to inject malicious code.
Data Processing: Applications may not properly validate external input data, leading to data tampering.

When integrity is compromised, systems can malfunction unpredictably or be completely taken over by attackers.

🕵️‍♂️ Common Examples of Software and Data Integrity Failures

In what cases can we say that the ‘integrity’ of software and data has failed?

1. Unverified Updates/Update Processes 🔄

Untrustworthy updates can be poison.

Problem: This occurs when the integrity of update files for applications, operating systems, firmware, etc., is not verified using digital signatures or hash values before download. If an attacker hacks an update server and distributes update files embedded with malware, users unknowingly install malicious code.
Example: During an OS update, failing to compare the hash value of the downloaded file with the official website’s value, leading to the installation of a tampered update and system infection.

2. Insufficient CI/CD Pipeline Integrity 🏗️

What if the process of creating software isn’t secure?

Problem: This happens when security is not properly applied to the entire process from a developer writing code to its deployment (CI/CD pipeline).
Code Repository Tampering: Attackers can hack code repositories like GitHub or GitLab to tamper with source code.
Build Server Infection: A build server can be infected with malware, causing legitimate code to be disguised as malicious code during the build process.
Example: An attacker gains access to a CI/CD server and injects malicious scripts, embedding backdoors into all deployed software.

3. Use of Untrusted Components/Libraries 📦

Even if my code is clean, what if someone else’s code is dirty?

Problem: This involves using unverified or ambiguously sourced open-source libraries or third-party components. (This is closely related to A06: Vulnerable and Outdated Components.)
Example: A legacy system uses an old library with a discovered Remote Code Execution (RCE) vulnerability, but it’s left unpatched, making it a target for attacks.

4. Insufficient Client-Side Integrity Verification 🌐

The problem of verifying data only on the client, not the server.

Problem: In web applications, user input data is validated only in the browser (client-side JavaScript) and not re-validated on the server. Attackers can easily bypass client-side validation and send tampered data to the server.
Example: In an online store, product prices are only validated client-side and not re-checked on the server, allowing an attacker to change the price to 0 using developer tools and complete the purchase.

5. Deserialization Vulnerabilities 👻

Hidden data bomb!

Problem: Occurs when an application processes untrusted data during the deserialization of serialized objects. Attackers can exploit this to trigger remote code execution.
Example: In applications using Java’s ObjectInputStream, PHP’s unserialize() function, etc., maliciously crafted serialized data is deserialized, leading to the execution of system commands.

🛡️ How Can We Prevent It? (Defense Methods)

The key to defending against software and data integrity failures is “validating all inputs and external incoming elements, and detecting changes.”

Digital Signature and Hash Verification ✍️✅: All software, libraries, update files, firmware, etc., must undergo integrity verification by checking digital signatures and comparing hash values (e.g., SHA256) before download and installation.
Strengthening CI/CD Pipeline Security 🏗️🔒:

Enhance access control for source code repositories and apply Multi-Factor Authentication (MFA).
Strengthen security across the entire CI/CD environment, including build servers and container image repositories, and regularly check for vulnerabilities.
Integrate automated security testing (SAST, SCA) into the CI/CD pipeline to detect tampered components or code before deployment.

Secure Component Management and SBOM Utilization 📦📝:

Create and manage a list of all third-party components used (SBOM: Software Bill Of Materials).
Only use trusted components without known vulnerabilities (CVEs) and update them periodically.

Robust Input Validation 🧐: Strong server-side input validation must be performed for all user inputs. Filter data based on an allowed character list (Whitelist) and strictly limit data format and length.
Secure Deserialization Implementation 🚫👻:

If possible, avoid using deserialization functionality or restrict deserialization to data from trusted sources only.
Verify data integrity before deserialization and specify allowed classes for deserialization based on a whitelist, not a blacklist.

✨ Conclusion

Software and data integrity failures represent a fundamental threat that renders our systems ‘untrustworthy’. We must always remember that a small broken piece can bring down the entire system.

From development to deployment and operation, continuous efforts and verification processes must be established to maintain integrity at every stage. Let’s firmly protect the ‘trust’ in our systems! 💪

Tags: OWASP, A08, Data Integrity, Software Integrity, Integrity, CI/CD Security, Deserialization, SBOM, Secure Coding