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.
