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.
