A modern web application rarely lives in a single codebase any more. The interface a customer clicks through is one system, built to be attractive and responsive, while the API underneath it handles the actual data, authentication and business logic. Testing only the part customers see and assuming the API behind it is equally covered is one of the more common and consequential mistakes businesses make, and it tends to go unnoticed until someone actively looks for it.
Two systems, two very different attack surfaces
The front end and the API each present a genuinely distinct attack surface, and a vulnerability in one rarely shows up if you only test the other. The front end is where issues like cross-site scripting and insecure client-side storage tend to live, exploitable through a browser and often visible during normal use. The API, meanwhile, handles authentication, authorisation and data access directly, and its flaws, broken object-level authorisation, excessive data exposure, missing rate limiting, are often invisible unless someone interacts with the API itself rather than the interface sitting in front of it.
A genuinely thorough assessment treats web application pen testing and dedicated API testing as two related but separate exercises, because a tester probing only the rendered pages of a single-page application will never see the majority of API endpoints that the application actually calls behind the scenes, some of which may not even be exposed through the visible interface at all, yet remain fully reachable to anyone who knows to look.
The endpoints nobody remembers exist
Modern applications frequently call far more API endpoints than any single view of the front end suggests, including endpoints built for a mobile app version, a partner integration, or an internal admin tool that shares the same backend. These endpoints often carry weaker authentication checks than the primary customer-facing flow, on the reasonable-sounding but flawed assumption that nobody outside the intended use case would ever find or call them directly, an assumption that rarely survives contact with a determined tester.
William Fieldhouse encounters this exact split constantly in web application engagements.
“We tested a retailer’s website and it looked genuinely solid from the browser, properly validated inputs, sensible session handling, all the basics done well. Then we pointed a proxy at the API directly and found an endpoint that returned any customer’s order history if you simply changed a number in the request. The front end had never called that endpoint in a way that exposed the flaw. It was still sitting there, fully reachable.”
— William Fieldhouse, Director of Aardwolf Security Ltd
That kind of broken object-level authorisation is one of the most common serious findings in API testing precisely because it is invisible from the front end. The interface only ever requests your own data, so nothing about normal browsing reveals that the underlying endpoint would happily return anyone else’s data too, given a slightly different request, which is exactly the kind of gap a determined attacker looks for.
Test both layers, not just the one you can see
Treat your web application as two connected but distinct systems requiring their own testing attention, not one assessment covering both by assumption. Map every endpoint the application actually calls, not just the ones visible through normal use, and test authorisation on each one individually through dedicated API pen testing rather than hoping front-end coverage extends that far. Contact Aardwolf Security for an assessment that genuinely covers both layers of your application, front end and API alike.
