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.
