Modern products are often a thin browser or mobile client in front of a larger API. A web application penetration test that only follows the UI can miss whole endpoint families, partner integrations and object-level authorisation flaws. An API test that ignores the browser surface can miss XSS, CSRF-class issues, DOM logic and session handling quirks that still matter to users.
This guide explains the practical difference, the weakness classes each engagement emphasises (including BOLA / IDOR-style authorisation failures), and when UK organisations should commission one scope or both.
Key points
- Web application testing: browser journeys, session management, injection, client-side issues, UI-driven workflows (OWASP Web Top 10 / WSTG).
- API testing: endpoints, tokens, object and function-level authorisation, mass assignment, rate limits, inventory (OWASP API Security Top 10).
- Need both when the UI and API are decoupled, when mobile or partners share the backend, or when enterprise buyers ask for both layers.
- A "web test" that never attempts cross-tenant object access is incomplete for multi-tenant SaaS.
- Combined scopes are often more efficient than two disconnected projects.
What a web application penetration test focuses on
A web application engagement follows user journeys through the browser (and intercepting proxies). Typical coverage includes:
- Authentication, session fixation and logout behaviour
- Access control across roles as exposed by the UI
- Injection (SQL, command, template) via forms and parameters
- Cross-site scripting and related client-side issues
- CSRF where cookie-based session models apply
- Business logic abuse reachable through the interface (price tampering, workflow skipping)
- Security headers, cookie flags and misconfiguration visible at the edge
Methodology commonly references the OWASP Web Security Testing Guide and the OWASP Top 10 risk categories for web applications.
APIs called by the front end are often exercised as part of those journeys. That is not the same as testing the full API catalogue, undocumented routes, or partner-only methods.
What an API penetration test focuses on
An API engagement treats the service contract as the product. Inputs include OpenAPI/Swagger specs, Postman collections, GraphQL schemas, and traffic captures. Emphasis shifts to:
- Broken Object Level Authorization (BOLA): changing an object ID (order, document, patient record) to access another user's or tenant's data. OWASP keeps the US spelling in these category names. BOLA sits at API1:2023 in the OWASP API Security Top 10 and overlaps with classic IDOR.
- Broken Function Level Authorization (BFLA): calling admin or privileged operations as a standard user.
- Broken Object Property Level Authorization: reading or writing fields the role should not see or modify (including mass assignment patterns).
- Authentication token handling, refresh flows and JWT misconfiguration
- Business flows that can be abused at scale, such as bulk sign-ups or purchases
- Unrestricted resource consumption and missing rate limits
- SSRF via URL-fetching parameters
- Improper inventory: shadow versions, debug endpoints, old APIs still live
- Unsafe consumption of third-party APIs
REST, GraphQL and SOAP each need slightly different techniques; the authorisation questions remain central.
Side-by-side comparison
| Dimension | Web application test | API test |
|---|---|---|
| Primary client | Browser UI | Direct HTTP/GraphQL clients |
| Catalogue | Pages and journeys | Endpoints and operations |
| Flagship weakness classes | XSS, CSRF, UI logic, session | BOLA/IDOR, BFLA, property-level authZ |
| Best artefacts from client | Role accounts, walkthrough | Specs, collections, token model |
| Missed if skipped | Client-side and cookie issues | Hidden and partner endpoints |
When you need a web application test
Commission web-focused work when:
- Customers primarily interact through a browser application
- Session and cookie security are material
- You are shipping UI-heavy workflows (approvals, content editing, admin consoles)
- A customer or framework questionnaire asks specifically for web application testing evidence
- Client-side trust boundaries matter (CSP, DOM sinks, third-party scripts)
When you need a dedicated API test
Commission API-focused work when:
- Mobile apps, SPAs or third parties call the same backend
- You publish a public or partner API
- Multi-tenant SaaS isolates customers by object IDs and tokens
- The front end is not the only client (integrations, batch jobs, webhooks)
- Previous "web" tests never documented negative authorisation cases across tenants
If your mobile app was tested but the shared API was not, you tested the wrapper, not the product.
When you need both
You typically need both layers when:
- Decoupled architecture: React/Vue/Angular (or similar) front end plus a substantial API
- Multiple clients: web + iOS/Android + partners
- Enterprise due diligence: buyers ask for OWASP Web and API coverage
- Regulated data over APIs: healthcare records, payment metadata, financial account objects
- Rapid endpoint growth: microservices where UI coverage lags the catalogue
A combined engagement lets consultants reuse role matrices, tenancy maps and business context. That is usually cheaper and clearer than two unrelated suppliers months apart.
Authorisation is the expensive path
For API-heavy products, the costly breach path is often not exotic RCE. It is authenticated abuse:
- Attacker registers or steals a low-privilege token
- Enumerates object IDs or guesses predictable references
- Reads or modifies another tenant's resources (BOLA / IDOR class)
- Calls privileged functions the UI never exposes (BFLA)
- Exports data at scale because rate limits and monitoring are weak
Web-only testing that never leaves the happy-path UI clicks can miss steps 2 to 5. API-only testing that ignores the browser can miss credential theft via XSS that then feeds the same API abuse. Both layers matter when both exist.
Finance APIs that expose payment instructions, healthcare APIs that expose clinical documents, media platforms with creator payouts, and technology SaaS with tenant isolation all share this pattern even when their UI aesthetics differ.
Scoping tips that prevent gaps
- Provide role accounts for every privilege tier you care about
- Share OpenAPI/GraphQL docs and note known gaps in documentation
- State whether web, mobile and partner clients share one API
- Agree whether undocumented endpoint discovery is in scope
- Clarify environment (staging versus production) and parity
- Ask the supplier to record negative tests: "User A could not access User B's object" is useful evidence when no finding exists
Attack Vector identifies security weaknesses across agreed web and API scopes and reports them so your teams can prioritise remediation. We do not take ownership of fixing your application code as part of the test fee.
What coverage claims do not prove
- Exercising APIs during a web journey is not automatic full API catalogue coverage.
- OWASP lists are risk reminders, not proof that every item was tested unless the report says so.
- GraphQL introspection being disabled does not equal solid authorisation.
- No test guarantees absence of BOLA; it shows whether skilled testing found exploitable instances in scope and time.
If you are unsure whether last year's web test covered the API you are about to expose to partners, ask for the endpoint list and authorisation matrix from that report. Gaps there are a scoping input, not a blame exercise.
Compare web application and API penetration testing service pages, then use the instant quote calculator or email [email protected]. Engagements start from £1,500 for a small, well-defined job. Broader catalogue: penetration testing services.
FAQ
Is BOLA the same as IDOR?
They overlap heavily. IDOR is a long-standing name for direct object reference flaws. BOLA is the OWASP API Security Top 10 framing for object-level authorisation failures on APIs. Reports may use either term; what matters is the evidenced cross-user or cross-tenant access.
Can one tester cover web and API in the same week?
Yes, when scoped that way. Day counts still rise with roles, endpoints and clients. Combined context helps; it does not erase surface area.
Do we need a public API to need API testing?
No. Private APIs used by your own SPA or mobile app are still attack surfaces once tokens are stolen or clients are reverse engineered.
Will providing Swagger reduce cost?
Clear specifications usually improve coverage quality and can reduce discovery time. They do not remove the need for negative authorisation testing.
Does SOC 2 or ISO 27001 require both?
Those frameworks are control-objective based rather than prescribing "web plus API" by name. Customer questionnaires and risk assessments often drive both in practice. See industry-aligned testing for how evidence is commonly packaged.
What should the report show if no BOLA was found?
Methodology notes and example negative test cases across tenants/roles. Silence without method is weaker than documented attempts that failed.
Suggested Resources
Ready to strengthen your security?
Talk to our consultants about your penetration testing requirements, or get a fast, transparent quote.