By Samyuktha
Introduction
There's a moment in every security review where you stop looking at the code and start asking a much older question: can I trust this? Trust who someone claims to be, and trust what a piece of software or data claims to be. That's really the throughline connecting OWASP's A07 and A08 categories.
A07: Authentication Failures asks whether an application can reliably verify who a user is — not just at login, but for as long as that user's session exists.
A08: Software and Data Integrity Failures asks a different but related question: can the application trust the software and data it receives before it acts on them?
I spent time studying both categories in depth and then, as I've done with the earlier posts in this series, tried to apply what I'd learned to an authorized web application. This time, though, the exercise turned out a little differently than my A03/A04 and A05/A06 write-ups. The application I had access to didn't yet have a completed production backend, a real authentication workflow, or backend-driven API functionality I could meaningfully interact with.
That constraint became a lesson of its own. It's tempting, when you've spent hours reading about a vulnerability class, to want to find something — to make the testing match the theory. But real security testing doesn't work that way. When the functionality needed to evaluate a control simply isn't there, the honest and professional response is to say so, not to manufacture a conclusion the evidence doesn't support.
Scope
- I studied OWASP A07 (Authentication Failures) and A08 (Software and Data Integrity Failures).
- I applied these concepts to an authorized web application.
- Testing was limited to accessible client-side functionality and observable behaviour only.
- No brute-forcing, destructive testing, unauthorized access, or data modification was performed at any point.
- Identifying details about the target have been omitted throughout. It is referred to only as "the assessed application."
Phase 1: A07 — Authentication Failures
"Are you really who you claim to be?"
That question sits at the center of A07. Authentication failures happen when weaknesses in the login process, credential handling, or session management let an attacker impersonate a legitimate user, sidestep authentication entirely, or exploit gaps in how identity is verified and maintained.
Login protections — Authentication isn't just a username-and-password check that either passes or fails. A well-built system also has to handle the failed attempts safely — because how it responds to repeated wrong guesses says a lot about how resilient it is to credential-guessing attacks. This is where concepts like rate limiting, temporary account lockouts, progressive delays between attempts, and proper detection and monitoring come in. None of these are exotic ideas, but skipping them is one of the more common ways authentication quietly breaks down.
Credential recovery — Password reset and account recovery flows deserve just as much scrutiny as the login form itself, if not more. A reset token that's predictable, one that never expires, one that can be reused, weak OTP handling, or a recovery flow with no attempt limits — any of these can turn a "forgot password" feature into a backdoor. Interestingly, some of these weaknesses blur the line with insecure design, because the underlying problem is often that security requirements were never built into the workflow in the first place.
MFA enforcement — Multi-factor authentication is often treated as a checkbox: it's either "on" or "off." But MFA that can be bypassed through a poorly protected recovery flow, or skipped entirely for certain sensitive actions, doesn't actually deliver the protection it promises. Having MFA present isn't the same as having it enforced everywhere it matters.
Session management — Authentication doesn't end the moment a user logs in — it continues for as long as their session is alive. That means the application also has to get session expiration right, invalidate sessions on logout, invalidate active sessions when a password or credential changes, and protect session identifiers from exposure or theft.
Authentication is more than verifying a password once. It is the entire process of proving identity, creating trust, and maintaining that trust throughout the session.
Phase 2: A08 — Software and Data Integrity Failures
"Can I trust this software or data before I use it?"
Where A07 is about identity, A08 is about integrity — making sure software or data hasn't been tampered with, whether unexpectedly or maliciously, before the application relies on it.
Software integrity — Applications routinely pull in updates, dependencies, or artifacts from somewhere else, and they need a way to confirm those things are what they claim to be. That's where hash verification, digital signatures, trusted publishers, and secure update mechanisms come in. It's worth separating the two main tools here: a hash is good at telling you something changed, while a digital signature goes further and helps establish who it actually came from.
Data integrity — The same skepticism applies to data. Applications shouldn't blindly trust externally supplied input before using it to drive sensitive actions. That said, it's worth being precise about scope — not every manipulated parameter automatically qualifies as an A08 issue. Whether something belongs in this category really depends on whether the root cause is improper trust in the integrity of software or data itself, rather than a different class of problem entirely.
Unsafe deserialization — Serialization is a simple enough idea once you strip away the jargon:
Object
↓
Serialized into transferable/storable data
↓
Later reconstructed by the application
The risk shows up when that final step — reconstruction — happens on data an attacker had a hand in shaping, and the application trusts it without question. I won't go into exploitation mechanics here; the important thing conceptually is that deserialization is a trust boundary, and treating it otherwise is where things go wrong.
CI/CD pipeline integrity — Even flawless application code can be undermined if the pipeline that builds and ships it isn't protected. Source repositories, build systems, deployment credentials, secrets, and the final build artifacts all need safeguarding — because a compromise at any one of those points can quietly introduce malicious changes into software that looks, on the surface, completely legitimate.
Integrity failures often begin when a system accepts something as trustworthy without first proving where it came from or whether it was changed.
Important Comparison: A07 vs A08
It helps to boil both categories down to a single question each:
A07: "Can I trust who this user says they are?"
A08: "Can I trust this software or data before processing it?"
One is about identity. The other is about origin and unaltered state. Different questions, but both fundamentally about trust that has to be earned by the system, not assumed.
Phase 3: Applying A07 and A08 to an Authorized Web Application
This is where theory meets the reality of what was actually available to test — and where I want to be especially careful to separate what I observed from what I could actually conclude.
Observed behaviour:
- The visible website was largely frontend/static in nature.
- The login and registration flow did not expose a completed, meaningful production backend authentication workflow.
- Regardless of whether a login attempt "succeeded" or "failed," the available flow led to dashboard.html.
- The dashboard itself appeared to be a demo or static implementation rather than a live, backend-driven interface.
- I found no meaningful authentication API or XHR activity tied to a real login or session workflow that I could inspect.
- No real session or token workflow was accessible.
- No meaningful protected backend functionality was available to test against.
A07 Findings
Because there was no completed backend authentication system in place, a full Authentication Failures assessment simply wasn't possible. What I could observe was limited to the visible login behaviour, the frontend flow itself, and the clear absence of a production-grade authentication workflow behind it.
What I could not honestly evaluate includes:
- Rate limiting
- Account lockout behaviour
- Password policy enforcement
- Password reset security
- MFA enforcement
- Session expiration
- Session invalidation
- Authentication token handling
I want to be explicit here: none of these should be read as secure or insecure based on this assessment. There simply wasn't enough backend functionality exposed to say either way.
No A07 Authentication Failure was confirmed within the limited accessible functionality. The absence of a completed backend authentication workflow prevented a meaningful assessment of the core authentication controls, and these areas should be retested once production authentication and backend functionality are available.
A08 Findings
The A08 assessment was similarly bounded by what was visible from the client side — things like JavaScript resources, external resources, client-side loading behaviour, and any visible third-party dependencies.
What fell outside the accessible scope includes:
- CI/CD pipeline integrity
- Internal build systems
- Build artifact signing
- Server-side data integrity controls
- Backend deserialization behaviour
- Software update verification mechanisms
I did not observe evidence of missing integrity checks or vulnerable dependencies, and I'm not going to claim otherwise just to fill out this section.
No A08 Software or Data Integrity Failure was confirmed within the visible client-side scope. A complete assessment would require access to backend processes, software delivery mechanisms, and internal integrity controls that were outside the accessible testing scope.
Conclusion
This assessment ended up teaching me as much about the limits of testing as it did about A07 and A08 themselves. Authentication can't be meaningfully evaluated without a real authentication system behind the login form. Integrity can't be fully assessed by looking only at a public-facing frontend. When a workflow is static or incomplete, those gaps become testing limitations — not findings, and not the absence of findings either.
Security testing has to run on evidence, not assumption. It would have been easy to speculate about what might be happening behind that login flow, but speculation isn't assessment. And just as importantly, the fact that I didn't confirm a vulnerability doesn't mean the application is secure — it means the evidence available to me didn't support that conclusion either way. Knowing what you can't conclude, and saying so plainly, is as much a part of professional assessment as reporting a confirmed finding.
Both A07 and A08 are worth revisiting once the assessed application has production backend functionality in place — a real authentication workflow, real session handling, and real backend processes to examine.
A professional assessment is not about filling every category with a finding. It is about understanding what the application actually allows you to verify — and being honest about everything that remains outside that evidence.
Responsible Disclosure
All testing described in this post was performed with proper authorization against an application I was permitted to assess. No destructive testing, brute-forcing, unauthorized access attempts, or data modification was performed. No identifying details about the target, its infrastructure, or its users have been shared.
Top comments (0)