OWASP Top 10 in Production: Real Exploit Chains We Found in Enterprise Penetration Tests

Every security team has read the OWASP Top 10. Fewer have seen what happens when those ten categories stop being a checklist and start being a live attack path inside a production system. At Nuage Security, our testers have logged more than 18,000 vulnerabilities across enterprise environments in finance, healthcare, SaaS, and logistics. What we keep seeing is not isolated findings. It is chains: a low severity issue in one part of an application combined with a misconfiguration in another, resulting in something the client's existing scanner never flagged at all.

This post walks through three anonymized exploit chains pulled directly from our testing engagements, what they reveal about how modern applications actually fail, and what your team can do this quarter to close the same gaps.

The OWASP Top 10 is a category list, not a severity list. A "Broken Access Control" finding on a marketing page is trivial. The same category on an internal admin endpoint can hand an attacker full administrative control. Automated scanners are good at spotting individual category matches. They are far weaker at recognizing when two or three medium severity issues combine into a critical one. That gap is exactly where a manual, attacker minded penetration test earns its value, and it is exactly where most "pentest" engagements that are really just a scan with a report template wrapped around it fall short.

The target was a B2B SaaS platform serving enterprise customers across multiple regions. The application used sequential numeric identifiers in its API for customer records, a textbook Insecure Direct Object Reference setup, which sits under the Broken Access Control category in the current OWASP Top 10.

On its own, this finding would typically be scored medium. A user could increment an ID in the URL and view another customer's record. But our testers did not stop there. While mapping the authorization model, we found that the same endpoint accepted a role parameter in the request body that was validated only on the client side, not the server. By combining the IDOR with a manipulated role parameter, our team escalated from a standard user account to an account with administrative read access across every tenant in the platform.

The result: a chain that started as a low effort enumeration bug ended in full multi tenant data exposure, the kind of finding that triggers mandatory breach disclosure under GDPR Article 33 and similar US state laws. The client's previous automated scan, run quarterly by an internal tool, had flagged the IDOR as low priority and never touched the role parameter at all, because automated tools test endpoints in isolation rather than as an attacker reasoning across the whole application.

Remediation: object level authorization checks enforced server side on every request, role validation moved entirely to the backend, and a logging rule added to flag any request where a client supplied role differs from the session's stored role.

This engagement targeted a fintech application with an image upload feature that allowed users to import a profile photo from a URL. This is a classic setup for Server Side Request Forgery, which falls under the OWASP category for security misconfiguration and increasingly gets its own dedicated line item due to how often it appears in cloud native applications.

Our testers supplied a URL pointing to the cloud provider's internal metadata service rather than an external image. The application server made the request as instructed, and the response, which should never have been accessible to an external user, contained temporary credentials tied to the server's IAM role. Those credentials granted read access to internal storage buckets containing transaction logs.

What made this chain dangerous was not the SSRF alone, which many teams now know to test for. It was that the cloud environment had no network level restriction blocking the application server from reaching the metadata endpoint, and the IAM role attached to that server had broader permissions than the application actually needed, a violation of least privilege that compounded the SSRF into a credential theft incident.

Remediation: metadata service access restricted at the network layer using instance metadata service version 2 with hop limits, strict allow listing on the image fetch feature, and IAM role permissions reduced to only what the application requires.

The third engagement involved a healthcare scheduling platform. A stored Cross Site Scripting vulnerability existed in a free text field used for appointment notes, a field that was rendered without sanitization in both the patient and administrator dashboards.

This alone would usually be scored medium to high. The chain became critical because the application stored session tokens in local storage rather than as HTTP only cookies. Our payload, planted through the appointment notes field, executed in the browser of any staff member who viewed that appointment, extracted the session token from local storage, and exfiltrated it to a testing controlled endpoint. With that token, our team authenticated directly as the staff member, bypassing multi factor authentication entirely since the session was already established.

This is a pattern we see repeatedly in healthcare and finance applications: strong authentication at login, paired with weak session handling that makes the authentication step almost irrelevant once an attacker gets a foothold elsewhere.

Remediation: input sanitization and output encoding on all user supplied free text fields, a strict Content Security Policy to block inline script execution, and a move from local storage to HTTP only, secure, same site cookies for session tokens.

All three of these findings exist because of how the vulnerabilities relate to each other, not because any single flaw was exotic. Automated tools are built to identify known patterns against individual endpoints. They generally do not model an authenticated user's full session behavior, they do not reason about IAM permission boundaries in context, and they do not chain a client side bug with a backend misconfiguration the way a human tester does. This is the core argument for manual, attacker minded testing as a complement to, not a replacement for, automated scanning.

Review object level authorization on every API endpoint, not just the ones flagged by automated tools.

Audit any feature that accepts a URL from a user, including image imports, webhooks, and PDF generators, for SSRF exposure.

Confirm session tokens are stored in HTTP only, secure cookies rather than local storage or session storage.

Apply least privilege to every IAM role attached to application servers, and test whether metadata endpoints are reachable from application code.

Schedule manual penetration testing at least twice a year, with scope that explicitly includes chained, multi step attack scenarios rather than single endpoint testing only.

These three chains are representative, not unusual. Across our engagements, the pattern holds: individually minor issues combine into critical breaches more often than any single catastrophic bug appears on its own. If your last security assessment came back with a short list of low and medium findings, that may say more about the scope and method of the test than about the actual state of your application.

Nuage Security's testing team is OSCP and CEH certified and runs manual, scenario based penetration tests designed to find exactly these kinds of chains before an attacker does. Request a sample report to see the level of detail our engagements produce, or get in touch to scope a test for your environment.