DEV Community: SAMYUKTHA SARAVANAN

OWASP A09 & A10: Seeing the Problem, Surviving the Failure

SAMYUKTHA SARAVANAN — Mon, 31 Aug 2026 04:48:49 +0000

By Samyuktha

Introduction

It's easy to think of security as a purely preventive discipline — block the attack, close the hole, stop the bad request before it lands. But prevention is only half the story. A genuinely secure system also has to notice when something suspicious does happen, and it has to keep behaving safely even when things go wrong in ways nobody planned for. That's the territory A09 and A10 cover, and it's a different kind of thinking than the categories I've written about so far in this series.

A09: Security Logging and Alerting Failures asks:

Can we see and respond when something suspicious happens?

A10: Mishandling of Exceptional Conditions asks:

What happens when something unexpected goes wrong?

As with the earlier posts, I studied both categories and then tried to apply what I'd learned to an authorized web application. And, much like last time, the accessible application had real limitations — the visible functionality was largely frontend/static and didn't expose a completed production backend.

That constraint ended up being one of the most useful parts of the exercise. Security testing runs on evidence. When visibility into a system is missing, the responsible move isn't to fill that gap with assumptions — it's to say plainly what could and couldn't be assessed.

Scope

I studied OWASP A09 (Security Logging and Alerting Failures) and A10 (Mishandling of Exceptional Conditions).
I applied these concepts to an authorized web application.
Testing was limited to accessible client-side functionality and observable behaviour only.
No destructive testing was performed.
No brute-forcing or repeated authentication attacks were performed.
No denial-of-service or resource exhaustion testing was performed.
No data modification or unauthorized access attempts were performed.
Identifying details about the target have been omitted throughout. It is referred to only as "the assessed application."

Phase 1: A09 — Security Logging and Alerting Failures

Security controls are not only about stopping attacks. Organizations also need to know when something suspicious has happened.

That's the idea underneath A09. It's not enough for a system to resist an attack — someone, somewhere, needs to know that an attempt was made at all. A09 covers the gap between "the attack was blocked" and "anyone actually found out about it."

It helps to separate four distinct ideas that often get lumped together:

Logging — recording security-relevant events as they happen.

Monitoring — actively reviewing those recorded events and identifying patterns that look suspicious.

Alerting — notifying the right people once something suspicious has been identified.

Response — investigating the alert and acting on it.

The flow looks something like this:

Security Event
↓
Log
↓
Monitor
↓
Alert
↓
Investigate
↓
Respond

Break any link in that chain and the whole thing stops working, no matter how strong the earlier steps are.

Important events need visibility — Plenty of application activity is security-relevant even if it doesn't look dramatic: failed authentication attempts, successful logins, password resets, account changes, privilege changes, administrative actions, access-control failures, and significant application errors. None of this means every application needs to expose these logs publicly — it means the organization behind the application needs internal visibility into them.

Logs without monitoring are not enough — A log file that nobody reads is functionally the same as no log at all. Recording an event is only the first step; someone or something has to actually review it and recognize when it looks wrong.

Detection without alerting is incomplete — Even a monitoring system that correctly flags suspicious activity is only useful if it can reach a human who can act on it. Detection that never triggers a notification is detection that changes nothing.

Context matters — A useful log entry gives an investigator enough to work with — what happened, when, and from where — without needlessly exposing sensitive data in the process. Logging too little makes investigation impossible; logging too much can create its own exposure risk.

Log protection matters — Logs are themselves a security asset. If an attacker can modify or delete them, they can erase the evidence of their own activity — which makes tamper protection for logs a control worth taking seriously in its own right.

A security event that nobody records is evidence lost. An event that nobody notices may become an incident discovered far too late.

Phase 2: A10 — Mishandling of Exceptional Conditions

What happens when the application encounters something it was not expecting?

Most application design centers on the happy path — the user logs in, submits the form, gets the expected result. A10 is about everything that happens when that path breaks down, and whether the application still behaves safely when it does.

Safe failure vs unsafe failure — When a security-relevant check can't complete normally, the outcome matters enormously. Two terms are useful here:

Fail-open — a security control fails, and the system allows the operation anyway.

Fail-closed — a security control can't verify the operation, so it blocks the sensitive action rather than guessing.

As a simple conceptual example: imagine an authorization check that's supposed to confirm a user has permission before a sensitive action proceeds. If that check throws an unexpected error, does the system default to allowing the action, or denying it? Fail-closed is almost always the safer default for anything security-sensitive — I won't go further into how such a check might be forced to fail, since that edges into exploitation territory.

Controlled error handling — Users need error messages that are useful without being revealing. Internal details like stack traces, file paths, database structure, internal architecture, or debug output shouldn't leak out through an error screen — that kind of information is far more valuable to an attacker mapping the system than it is to a legitimate user trying to understand what went wrong.

Partial failures — Many workflows involve multiple steps chained together, and it's entirely possible for one step to succeed while the next one fails. A system needs a deliberate answer for what happens in that in-between state, rather than leaving things in an inconsistent or undefined condition.

Third-party service failures — Modern applications lean on external services constantly — authentication providers, payment processors, email systems, third-party APIs, cloud infrastructure. When one of those dependencies fails or times out, the application has to handle that uncertainty safely rather than assuming the best case.

Resource failures — Every system has finite resources, and exceptional-condition handling includes thinking about timeouts, request limits, file limits, connection limits, and graceful degradation when those limits are reached. I won't get into how those limits might deliberately be exhausted — that's outside what this post is meant to cover.

Security is not only about how an application behaves when everything works. It is also about how safely it behaves when nothing goes according to plan.

Important Comparison: A09 vs A10

A09: Can we see and respond to suspicious activity?
A10: Can the application handle unexpected failures safely?

A simpler way to hold onto the distinction:

A09 → Can we detect the problem?
A10 → Can we handle the problem safely?

Phase 3: Applying A09 and A10 to an Authorized Web Application
Important application context

The assessed application, as with the previous post in this series, currently has limited accessible production functionality.

Observed behaviour:

The visible website was largely frontend/static.
The accessible login and registration flow did not expose a completed, meaningful production backend authentication workflow.
Different login attempts did not lead to a meaningful, observable authentication decision.
The accessible flow consistently led to dashboard.html regardless of the attempt.
The dashboard appeared to be a static or demo implementation.
No meaningful authentication API or XHR activity tied to a real backend login/session workflow was available to inspect.
No real session or token workflow was accessible.
No meaningful protected backend functionality was available for testing. I want to be direct about what this does and doesn't mean: the login page here should not be treated as evidence of a real, functioning authentication system. What I observed is just as consistent with an incomplete or demo-stage frontend as it is with anything else, and I'm not going to label it a vulnerability without evidence to back that up.

Applying A09

A09 is genuinely difficult to assess from an external, frontend-only vantage point, because the controls it's concerned with — logging, monitoring, detection, alerting — live almost entirely on the internal side of a system. I had no access to:

Server logs
SIEM platforms
Detection rules
Security alerts
SOC monitoring processes
Incident response workflows
Log retention controls
Log integrity controls

And because the accessible authentication workflow never generated meaningful backend authentication activity to begin with, I also couldn't observe things like failed-login logging, successful-login logging, authentication alerts, password reset events, or administrative security events — there was simply no real event stream to watch.

It's important not to overreach here. The absence of visible logs does not mean the organization has no logging in place. It means I, from where I was standing, couldn't see any — and that's a visibility limitation, not a confirmed failure.

No A09 Security Logging and Alerting Failure was confirmed within the accessible external scope. A meaningful assessment of internal logging, monitoring, detection, and alerting controls wasn't possible, since those mechanisms sit outside the visible testing environment — and the accessible application didn't provide a completed backend workflow capable of generating the kind of security events that would need to be observed.

Applying A10

A10 could only be approached through limited observation of frontend behaviour, for the same underlying reason as A09: the application didn't expose meaningful backend functionality. That put a hard ceiling on what I could realistically assess, including:

Database failures
Backend service failures
API timeouts
Authentication service failures
Authorization service failures
CI/CD failures
Internal dependency failures
Resource exhaustion behaviour
Server-side exception handling

Deliberately triggering outages, crashes, or resource exhaustion was outside the scope of this assessment from the start, so those areas weren't tested by design, not just by circumstance.

The one thing worth calling out is that the login behaviour was a little unusual — different attempts all led toward the same static dashboard.html. It would be tempting to read that as an A10 finding, but I don't think the evidence supports that conclusion.

Incomplete or demo functionality is not automatically evidence of insecure exceptional-condition handling.

I've documented this as a testing limitation, not a confirmed security issue. Calling it an A10 vulnerability would require evidence that a genuine exceptional condition led to an insecure fail-open state, exposed sensitive information, or produced unsafe system behaviour — and that evidence wasn't there.

No A10 Mishandling of Exceptional Conditions issue was confirmed within the accessible functionality. The available frontend offered insufficient visibility into backend failures and internal service behaviour, so the core fail-open/fail-closed controls and server-side exception handling could not be meaningfully assessed.

Key Lesson From the Assessment

If there's one thing this round of testing reinforced, it's that not every OWASP category can be fully tested from a public frontend. Some categories depend on visibility into backend systems, server logs, security monitoring, authentication infrastructure, internal error handling, and service dependencies — none of which are reachable from outside the perimeter of what's publicly exposed.

Guessing is not security testing. A professional assessment has to hold its conclusions to what the evidence actually shows, which means sorting everything into what was tested, what was observed, what remains not confirmed, and what was simply not testable given the scope.

The goal of an assessment is not to force every category into a finding. It is to understand what the available evidence actually supports — and to leave the rest honestly unresolved.

Conclusion

A09 taught me that detection matters just as much as prevention. A system can have strong security controls in place and still fall short if suspicious activity goes unrecorded or unnoticed — the controls only matter if someone knows they were tested.

A10 taught me that secure systems have to be designed for failure, not just for success. Unexpected conditions shouldn't be allowed to silently disable the security checks that were supposed to be protecting the system in the first place.

More than anything, this hands-on assessment reinforced the value of recognizing testing limitations for what they are. The accessible application simply didn't expose enough backend functionality to fully assess either category, and no vulnerability should be invented just to check a box on an OWASP list. A09 and A10 are both worth revisiting once the production backend and meaningful workflows are actually in place.

Good security testing is not about proving that something is broken. It is about understanding what can be verified, documenting what cannot, and refusing to turn assumptions into findings.

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, denial-of-service testing, unauthorized access attempts, or data modification was performed. No identifying details about the target, its infrastructure, or its users have been shared.

OWASP A07 & A08: Trusting Identity, Trusting Integrity

SAMYUKTHA SARAVANAN — Sun, 30 Aug 2026 14:19:28 +0000

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.

OWASP A05 & A06: When Injection and Insecure Design Meet an Incomplete Application

SAMYUKTHA SARAVANAN — Fri, 28 Aug 2026 10:14:51 +0000

By Samyuktha

Introduction

After spending time with Broken Access Control and Security Misconfiguration in my last write-up, I moved on to two categories that sit closer to how an application handles data and how it was planned in the first place: A05, Injection, and A06, Insecure Design. A05 is about what happens when untrusted input is allowed to influence backend processing in ways it shouldn't. A06 is a step earlier than that — it's about whether the right security questions were even asked before a feature was built, and whether realistic abuse cases were considered during design.

I studied both categories in depth and then tried to apply what I'd learned to an authorized web application. I want to be upfront about how this one turned out: the assessment did not produce a confirmed vulnerability, because the functionality I could actually reach had real limitations. That might sound like an anticlimactic way to open a write-up, but I've come to think that recognizing the boundaries of what you can honestly test is just as much a part of a real assessment as finding something exploitable. Knowing where your evidence runs out is a skill in itself, and pretending otherwise is how weak findings end up in reports.

Scope

This write-up covers my study of A05 (Injection) and A06 (Insecure Design), and my attempt to apply both concepts to an authorized web application. I reviewed the input points and workflows that were accessible to me at the time of testing. No destructive testing, brute-forcing, unauthorized access attempts, or data modification was performed at any point. Identifying details about the target have been intentionally omitted, and I'll refer to it only as "the assessed application" throughout.

Phase 1: A05 — Injection

Injection, at its core, is about untrusted input reaching somewhere it can influence behavior it shouldn't be able to. If a user-controlled value ends up shaping a query, a command, or some other piece of backend logic in a way the developers didn't intend, that's the shape of an Injection issue. It's a simple idea in concept, but figuring out whether it actually applies to a given input takes more discipline than it sounds like.

The first practical step is just identifying where user input enters the application at all. Search fields, login forms, registration forms, filters — anywhere a user gets to type something and the application does something with it is worth a look. None of these are automatically dangerous, but they're the starting points worth paying attention to.

Frontend vs backend processing — one of the more useful distinctions I sharpened while studying this category is that not every input field is equal. An input that's filtered or validated entirely in the browser, with JavaScript deciding what happens next, is a fundamentally different thing from an input that gets sent off to a backend for processing. Local, client-side filtering on its own doesn't give you a meaningful path toward testing something like SQL Injection — there's no query being built, no database being touched, nothing happening beyond the browser tab. Once an input actually reaches a backend, that's when it becomes a genuine candidate for investigation. But I want to be clear that this is only the first filter, not the finish line — an input reaching a backend does not, by itself, mean SQL Injection exists. It just means there's something worth looking at more closely.

Baseline first — before trying to interpret anything as unusual, you need to know what normal looks like. Submitting expected, well-formed input and watching how the application responds gives you a reference point. Without that baseline, an odd response later on is just noise — you have nothing to compare it against, and no way to say with any confidence that something changed because of what you sent.

Evidence, not assumptions — this is probably the part of A05 testing that gets rushed the most, and it's the part I tried hardest to slow down on. A single error message is not proof of Injection. Applications throw unexpected errors for all kinds of reasons — input validation catching something it wasn't built to handle, a genuine bug, a WAF or filtering layer doing its job. A real finding needs to be reproducible, and it needs to demonstrate an actual security impact, not just an anomaly. It's tempting to see one strange response and want to call it a finding. Slowing down and asking whether you can actually reproduce and explain the behavior is what separates a real result from a guess.

A backend request is not the same thing as a confirmed Injection vulnerability. The important question is whether untrusted input can demonstrably influence backend processing in an unsafe way.

For context, Injection issues are usually grouped into a few recognizable categories — error-based, boolean-based, union-based, and blind — depending on how the application reveals (or hides) the effect of the injected input. I won't turn this into a payload walkthrough; the categories are just useful vocabulary for thinking about how evidence might present itself if a real path existed.

Phase 2: A06 — Insecure Design

If A05 is about what untrusted input can do once it reaches a backend, A06 is about a question that comes much earlier: was the feature ever designed with abuse in mind at all? This was the category that shifted how I think about testing the most.

Threat modeling changes the question — most testing instinct starts with "can I break this?" — can I bypass this check, can I trigger an error, can I get past this control. Insecure Design asks something different: "can I abuse this feature even if it works exactly as intended?" A feature can function flawlessly, with zero bugs, and still be insecure by design if nobody thought through how it could be misused. That distinction matters, because Insecure Design issues often exist before a single line of code is written — they come from gaps in the requirements and planning stage, not from implementation mistakes.

Thinking this through in practice comes down to a few recurring questions. Before a feature ships, someone should have decided who is allowed to use it, what they're allowed to do with it, what limits should exist around it, and what the consequences are if it gets abused. When those questions are skipped or answered incompletely, the feature can go on to work "correctly" while still being unsafe.

Workflow and business logic abuse — this is where those design gaps tend to show up in practice. A feature might allow an action to be repeated far more than intended, let a limit be exceeded, allow an important step to be skipped, or tolerate steps happening in an order nobody planned for. None of these require breaking anything technically — they just require noticing that the workflow doesn't enforce the boundaries it should.

Appropriate limits are usually the concrete fix for this: attempt limits, expiration windows, verification steps, one-time-use controls, and other protections scaled to the actual risk of the feature. A classic, low-drama example is a password-reset flow that works exactly as designed — the reset email goes out, the code is generated correctly, the reset itself functions fine — but the design never places a limit on how many times a verification code can be attempted. Nothing is technically broken. The design simply never accounted for someone trying the code repeatedly.

Insecure Design often begins before the code is written — when the system's security requirements fail to account for realistic abuse cases.

Phase 3: Applying It to an Authorized Web Application

With both categories studied, I moved on to the assessed application, trying to approach the accessible functionality with the mindsets I'd just built out for A05 and A06.

A05 — what I found. I looked through the available input points — the login and registration forms mainly — and tried to determine whether the values I entered were producing meaningful backend interaction, rather than assuming every form field was automatically a testable Injection target. This is where the assessment ran into its main limitation. Regardless of whether the credentials I submitted were valid or invalid, the login and registration flow consistently redirected to a page called dashboard.html. The dashboard itself appeared to be a static or demo-style implementation rather than something backed by live application state. I didn't observe meaningful API or XHR activity that would indicate a real, functioning authentication workflow behind the forms I was testing. Without that, I didn't have enough genuine backend-driven functionality to conduct a meaningful Injection assessment. No A05 Injection vulnerability was confirmed.

I want to be precise about what that does and doesn't mean. It does not mean the eventual production backend is secure, and it would be dishonest to imply that. It means the currently accessible functionality didn't give me a real path to test against. The backend and any relevant API-driven input flows should be retested once they're actually in place.

A06 — what I found. I reviewed the same accessible functionality with an abuse-case mindset — asking what each feature was supposed to do, who should be able to use it, what limits ought to apply, whether an action could be repeated beyond reason, and whether steps could be skipped or reordered in a way that mattered. But the same limitation that affected A05 applied here too. The login, registration, and dashboard functionality available to me didn't reflect a completed production workflow — there were no meaningful state changes to observe, and no protected backend actions I could actually probe for workflow abuse. Without real workflows in front of me, I couldn't honestly validate any realistic abuse scenario. No A06 Insecure Design vulnerability was confirmed.

Again, this reflects a limitation in what was available to test, not evidence that the application's design has no weaknesses. Production workflows should be reassessed once they're complete.

No A05 Injection vulnerability was confirmed within the currently accessible functionality. A complete assessment will require retesting when production backend functionality and relevant API-driven input flows are available.

No A06 Insecure Design vulnerability was confirmed within the limited functionality available for testing. A meaningful assessment of workflow security will require access to completed production workflows and backend-supported features.

Conclusion

Not every OWASP category can be meaningfully tested against an application that isn't fully built out yet, and I think this assessment made that clearer to me than any of my previous ones. A form sitting on a page doesn't prove Injection is possible. A request reaching a backend doesn't prove SQL Injection exists. A real A05 finding needs reproducible evidence and a demonstrable impact, and I didn't have the functionality in front of me to produce either. A06 asks for something different but equally demanding — real workflows, real state changes, real consequences to reason about — and a static or demo-style dashboard doesn't offer enough of that to draw honest conclusions from.

What I can say clearly: I tested the accessible login, registration, and dashboard functionality. I observed that authentication outcomes, successful or not, led to the same static dashboard page, with no meaningful backend-driven behavior visible from that flow. Whether deeper Injection or design weaknesses exist in the real backend and workflows remains inconclusive, simply because that functionality wasn't available to test. Both categories are not yet testable in any complete sense, and both should be revisited once production backend, authentication, API, and workflow functionality are in place.

A good assessment does not force a vulnerability where the evidence isn't there. It documents what was tested, what was inconclusive, and what needs to be revisited when additional functionality becomes available.

I'll be coming back to A05 and A06 once there's a real backend and real workflows to test against — this write-up is a checkpoint, not a closed chapter.

Responsible Disclosure

All testing 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 in this write-up.

OWASP A03 & A04: Understanding Software Supply Chain and Cryptographic Failures

SAMYUKTHA SARAVANAN — Thu, 27 Aug 2026 06:30:34 +0000

By Samyuktha

Introduction

Some categories in the OWASP Top 10 are about what's broken in your own code. A03 and A04 are about something a little different — whether you can trust what your application depends on, and whether sensitive data is actually protected wherever it lives or travels. This post covers what I learned about both categories, and how I applied that thinking to an authorized web application afterward.

The result wasn't a dramatic one, and part of it wasn't even fully testable. Both of those turned out to be useful lessons in their own right.

Scope: This post covers concepts I studied around A03 and A04, plus a hands-on look at the client-side resources, storage, and login/dashboard flow of an authorized application. No destructive testing was performed, and identifying details about the target have been omitted. I'll refer to it simply as the assessed application.

Phase 1: A03 — Software Supply Chain Failures

This category covers what happens when an application depends on components that are compromised, vulnerable, outdated, unverified, or poorly managed — libraries, packages, SDKs, APIs, models, even the CI/CD pipeline that builds and ships everything.

A few concepts stood out:

Third-party risk isn't your code, but it's still your problem — a vulnerability doesn't have to originate in your own codebase to affect your application. It can arrive through a dependency you imported once and never revisited.

Build pipeline integrity — an insecure or poorly monitored CI/CD process can be just as dangerous as a vulnerable library, since it controls what actually reaches production.

Provenance matters — knowing where a component came from, and whether it's been tampered with, is as important as knowing what it does.

Continuous tracking, not one-time review — dependencies need to be monitored and patched on an ongoing basis, not just checked once at integration time.

The SolarWinds incident is the go-to example here — attackers compromised a build system and slipped malicious code into a trusted update, which then propagated to thousands of downstream organizations without any of them doing anything wrong on their end.

An external dependency is not automatically a vulnerability. A real supply chain finding requires evidence that the component is vulnerable, compromised, insecurely managed, or otherwise creates a demonstrable security risk.

Phase 2: A04 — Cryptographic Failures

This category covers inadequate protection of sensitive information — during transmission, storage, authentication, or processing. It's tempting to think of this as "broken encryption," but it's broader than that:

HTTPS enforcement across the application
Sensitive data transmitted without proper encryption
Sensitive information exposed in URLs
Sensitive data stored insecurely client-side
Authentication and session cookie handling
Cookie attributes such as Secure, HttpOnly, and SameSite
Local Storage and Session Storage contents
Sensitive fields exposed through API responses

What stood out here is that even a perfectly implemented algorithm doesn't help if a token ends up sitting unprotected in local storage or riding along in a URL. Cryptographic failures are as much about handling as they are about math.

Cryptographic failures are not limited to broken encryption algorithms. They can also happen when sensitive information is not properly protected.

Phase 3: Applying It to an Authorized Web Application

With both categories fresh, I applied the same checklist to an authorized web application, staying within the accessible, permitted scope.

For A03, I inspected the application's visible client-side resources. I reviewed the main JavaScript file for import statements, require() calls, third-party library signatures, CDN references, and visible dependency versions, and mapped the resources the HTML actually loaded.

Result: the JavaScript I reviewed appeared to use standard browser APIs and first-party functionality — no obvious third-party imports or exposed version strings. CSS, JavaScript, and most assets were served locally. The one visible external runtime resource was Google Fonts, which I noted as an external dependency but not a finding, since nothing indicated it was compromised or insecurely integrated. Social media, map, and app-store links were outbound references, not dependencies, so I didn't treat them as supply chain scope. No confirmed A03 finding was identified within the visible client-side components I assessed — that conclusion doesn't extend to server-side dependencies or build pipelines outside my visibility.

For A04, I worked through the checklist directly: whether HTTP redirected to HTTPS, whether sensitive data showed up in URLs, what was sitting in Local Storage and Session Storage, and how cookies were configured.

Result: HTTP redirected successfully to HTTPS. No obvious passwords, tokens, or similar sensitive information were observed in the URLs I inspected. No obvious sensitive authentication data was observed in Local or Session Storage. The cookies visible during testing appeared to be analytics-related rather than an identifiable application authentication session cookie, so I could not fully assess authentication cookie attributes like Secure, HttpOnly, and SameSite.

I also tried to walk through the login and dashboard flow, and that's where I hit a real limitation rather than a finding. The production application isn't fully built out yet — the login/registration flow didn't lead to a completed production backend, and the available dashboard appeared to be a demo or static implementation with no meaningful authenticated workflow and no backend API activity to inspect. That means real session handling, token management, and protected API responses simply weren't available to test.

No A04 Cryptographic Failure was confirmed within the accessible functionality. A complete assessment will require retesting once the production backend, real authentication, and API functionality are available.

Conclusion

This round reinforced something I'm noticing as a pattern: knowing what you can't conclude yet is as important as what you can. It would have been easy to call Google Fonts a supply chain risk, or the incomplete login flow broken authentication — but neither would have been an honest read of what I actually observed. A partial, well-scoped result beats an inflated one.

A good assessment separates what was tested and clean, what was observed but inconclusive, and what simply couldn't be tested yet — and says so plainly.

Next, I'm planning to work through A05 and revisit A04 once more of the application's backend is available, so this becomes a proper retest rather than a fresh look.

Responsible Disclosure

All testing described here was performed with proper authorization against an application I was permitted to assess. No identifying details about the target, its infrastructure, or its users have been shared.

OWASP A01 and A02: Broken Access Control and Security Misconfiguration

SAMYUKTHA SARAVANAN — Wed, 26 Aug 2026 13:06:13 +0000

By Samyuktha

Introduction

Not every learning exercise ends with a dramatic finding, and that's a fine outcome. This post walks through two OWASP Top 10 (2025) categories I studied hands-on via TryHackMe — A01: Broken Access Control and A02: Security Misconfiguration — and how I applied that thinking to a real, authorized production web application afterward.

The result on the real target wasn't a vulnerability. It was a clean pass. That turned out to be its own useful lesson about what a methodical assessment actually looks like.

Scope: This post covers concepts from two TryHackMe rooms plus a brief, authorized look at a production login/dashboard flow. No destructive testing, brute-forcing, or data modification was performed, and identifying details about the target have been omitted.

Phase 1: A01 — Broken Access Control

Broken access control is consistently ranked the top web application risk, and going through the room made clear why: it's less about clever exploitation and more about the server trusting things it shouldn't.

A few concepts stood out:

IDOR (Insecure Direct Object Reference) — when an app exposes an internal identifier (like a numeric user or order ID in a URL or request body) and doesn't verify the requester actually owns that resource. Swap the ID, and you may be looking at someone else's data.

Missing function-level access control — a feature like an admin panel might be hidden from the UI for regular users, but if the endpoint itself doesn't check role server-side, it's still reachable by anyone who finds or guesses the URL.

Privilege escalation via parameter tampering — modifying a role or permission value in a request (for example, a role field) to see if the server blindly trusts what the client sends.

Forced browsing — manually requesting pages that aren't linked in the UI but still exist and respond on the server.

The recurring theme: hiding something in the UI is a design choice, not a security control. Every sensitive action needs to be re-checked server-side, every time.

Phase 2: A02 — Security Misconfiguration

This category is less about flawed logic and more about the gap between "the app works" and "the app was actually hardened" — defaults, leftovers, and things nobody circled back to clean up:

Default or sample credentials still active
Verbose error messages leaking stack traces, file paths, or framework versions
Directory listing left enabled
Missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security)
Outdated software with known CVEs still running in production
Unnecessary services or ports left exposed

What stood out here is how mundane most of these issues actually are. They're rarely clever — they're just things nobody revisited before shipping. Which also makes them some of the easiest wins in a real assessment, when they exist.

Phase 3: Applying It to a Real Target

With those two categories fresh, I got the chance to apply the same checklist to a live production web application I was authorized to test, using Burp Suite to intercept and review the login and post-login dashboard flow.

I went through the A01 checklist specifically:

Tested for IDOR by swapping identifiers in requests made with my own low-privilege account
Checked whether role-restricted functionality was reachable directly, bypassing the UI
Compared what the UI exposed against what the server actually permitted
Spot-checked response headers and error handling for A02-style misconfiguration signs

Result: nothing exploitable turned up. No accessible IDOR, no reachable hidden admin functionality, no glaring header or error-handling issue in what I checked.

A clean result isn't a failed assessment — it's evidence the access control model held up under a defined set of tests, plus a documented baseline for the next round.

Conclusion

This exercise reinforced something the labs don't always emphasize as strongly as real targets do: a negative result is still a result. It's tempting, especially early on, to feel like an assessment only "counts" if it turns up a finding. But ruling things out methodically — and being honest that nothing jumped out — is exactly what a real assessment looks like most of the time.

Good security testing isn't about finding the most dramatic bug. It's about applying the checklist consistently and being straightforward about what did and didn't hold up.

Next, I'm planning to work through A03: Injection and start keeping more structured notes so these write-ups build into an actual testing checklist over time.

Responsible Disclosure

Any production testing referenced here was performed under authorized scope as part of a formal assessment, and identifying details about the target have been omitted from this post.

From a Static Marketing Site to a Live Production API: A Web Application Security Walkthrough

SAMYUKTHA SARAVANAN — Tue, 25 Aug 2026 13:26:12 +0000

By Samyuktha S

Introduction

Not every security assessment ends with a critical vulnerability — and that's fine. Real-world testing involves mapping, dead ends, false positives, and genuine findings.

This post covers an authorized assessment of a healthcare recruitment/networking platform [TARGET]. The assessment started with a static front-end, then moved to the real production application discovered through subdomain enumeration, resulting in two findings worth reporting.

The key lesson is simple: verify before claiming. Some things initially looked vulnerable but were ruled out after testing.

Scope: TARGET and associated subdomains. No destructive testing, brute-forcing, or data modification was performed.

Phase 1: Mapping the Surface
The assessment began with the primary domain, which contained a homepage, login, registration, job portal, and contact form.

Basic reconnaissance — including viewing page source, inspecting network requests, and reviewing JavaScript — showed that these features had no real backend.

The login button performed a client-side redirect without submitting credentials or sending a request. The dashboard displayed the same hardcoded content regardless of authentication state. Registration, contact, and job-related forms followed a similar pattern.

This was not treated as an authentication bypass because there was no real data or backend logic behind these pages. However, it was worth noting as a design issue that could become risky if a real backend is later connected.

Phase 2: Finding the Real Application
The next step was passive subdomain enumeration using publicly available information, including Certificate Transparency logs and passive DNS sources.

This revealed an API host and a corresponding application host.

Unlike the primary domain, these were active production systems. The application was a real single-page application backed by an Express.js API with OTP authentication, role-based data, and a REST API.

This became the focus of the assessment.

Phase 3: Testing and Ruling Things Out
CORS Headers — Investigated, Not Exploitable
The API returned:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

This looked concerning because it appeared to allow any origin to make credentialed requests.

However, testing showed that the server returned a static * rather than reflecting arbitrary origins.

Browsers do not allow credentialed CORS requests with a wildcard origin, so no working exploit could be demonstrated.

Conclusion: A configuration issue worth cleaning up, but not a confirmed vulnerability.

A suspicious configuration should always be tested before being reported as exploitable.

Phase 4: Two Findings That Held Up
Finding 1 — Authentication Token Stored in Browser localStorage
The application's JavaScript showed that authentication tokens and user-related information were stored in localStorage:

localStorage.setItem("userToken", [TOKEN]);
localStorage.setItem("userId", [USER_ID]);
localStorage.setItem("roleId", [ROLE_ID]);

Unlike HttpOnly cookies, localStorage can be accessed by JavaScript running on the same origin.

This means a future XSS vulnerability could potentially expose authentication tokens and user information. No XSS vulnerability was claimed during this assessment, but this design increases the impact of any future XSS issue.

Severity: Low–Medium

Remediation: Consider storing authentication tokens in HttpOnly, Secure, and appropriately configured SameSite cookies, with CSRF protections where necessary.

Finding 2 — Possible User Enumeration via Password Reset Endpoint
The password-reset endpoint returned a distinct response for a non-existent account:

POST /api/user/forgot-password/send-otp
{
"email": "[NONEXISTENT_TEST_EMAIL]"
}
Response:
{
"message": "User not found"
}

This could allow attackers to determine whether an email address is registered if valid accounts receive a different response.

Important limitation: I did not test a real user's email address for comparison because that was outside the authorized scope. Therefore, this is reported as a probable user enumeration issue rather than a fully confirmed vulnerability.

The platform owner can confirm this internally using an authorized test account.

Severity: Low–Medium

Remediation: Return the same generic response for both existing and non-existing accounts, for example:

If an account is associated with this email address, an OTP has been sent.

Response timing should also be kept as consistent as practical to reduce timing-based enumeration.

Conclusion
This assessment reinforced the importance of not overstating findings.

The accessible dashboard and CORS configuration initially looked concerning but did not result in a confirmed exploit. The token storage design and probable password-reset enumeration issue, however, were worth reporting.

Good security testing is not about finding the most dramatic vulnerability. It's about verifying what is actually exploitable and being honest about what cannot be confirmed.

Responsible Disclosure
The findings were reported to the platform owner before publication. Sensitive, proprietary, and identifying details have been omitted from this post.

Have questions about this methodology or want to discuss the findings? Feel free to reach out.