Web App + API Pentest: Why Split Testing Fails

Broken object-level authorization is API1:2023 on the OWASP list, consistently reported as one of the most common critical findings in API security assessments across the industry. It is also invisible to a test that only touches your application through a browser. Change /api/orders/4471 to /api/orders/4472, and if the API does not check whether that order belongs to you, someone else's invoice loads. No frontend bug required.

That is the gap that shows up again and again once a "clean" web app pentest report has already been filed. The browser layer looks secure because the frontend hides the buttons a user should not see. The API behind it, the part that actually decides who gets what data, was never in scope.

A modern web application is really two systems stacked on top of each other. There is the client-facing layer: the pages, forms, and session handling a user interacts with through a browser. And there is the API layer underneath: the endpoints that the frontend calls, and that mobile apps, partner integrations, and automation scripts often call directly too.

A web application pentest that only exercises the app through the browser tests the first layer. It clicks through login flows, checks for stored XSS, probes CSRF protections, and looks at how sessions are handled. All necessary work. But an attacker does not need a browser. They open Burp Suite, capture the API calls the frontend makes, and start sending requests directly, skipping every validation rule the frontend UI enforces.

This is exactly why the OWASP API Security Top 10 treats API testing as its own discipline, separate from the OWASP Web Security Testing Guide used for the browser layer. The two lists cover different failure modes, and a tester scoped only against one of them will not go looking for the other.

A Standard Web App + API Pentest engagement tests both layers as one connected system, because that is how they actually work in production.

On the web application side, testers work through OWASP Testing Guide methodology: authentication and session management, input validation, access control logic, business logic flaws, client-side security controls, and configuration issues across the full user-facing surface.

On the API side, testing follows OWASP API Security Top 10 categories directly against the endpoints: broken object-level and function-level authorization, excessive data exposure, mass assignment, rate limiting gaps, and authentication weaknesses in tokens and API keys. REST and GraphQL endpoints are tested with authenticated tooling, not just automated scanning, meaning a human tester manually attempts privilege escalation and data exposure, not just a scanner flagging missing headers.

The two halves are tested together specifically to catch the failure mode where the frontend correctly hides an action, but the API behind it still executes it for any authenticated user who knows the endpoint exists.

Splitting web and API into two separate purchases seems like it spreads out the budget. In practice it usually means the API assessment gets postponed indefinitely once the web report comes back clean, because a clean report reads as "we're covered."

There is also a scoping cost. When testers assess web and API together, they build one shared understanding of the application's authentication model, user roles, and data flow, then test both surfaces against that model. Splitting the work into two separate engagements means paying twice for reconnaissance and scoping, often with two different teams who never compare notes on what they each found.

For teams building with a decoupled frontend and a REST or GraphQL API, which is how the majority of modern SaaS products are architected, combined testing is not an upsell. It is testing the application as it actually exists.

A Standard Web App + API Pentest engagement closes with a report mapped to concrete, reproducible findings rather than a raw vulnerability list: each issue includes a proof of concept, severity rating, affected endpoint or page, and specific remediation guidance a developer can act on without translating security jargon first. Findings that touch compliance-relevant data get flagged against the standards most EU and US clients are asked about during audits, including OWASP Top 10 and OWASP API Security Top 10 mappings. A free retest after fixes ship confirms whether each finding is actually closed, not just marked resolved on a spreadsheet.