API vs web application penetration testing: scope, methodology, and when you need both

Web application penetration testing examines the browser-facing surface: HTML rendering, JavaScript execution, session management, and client-side controls. API penetration testing targets backend endpoints directly, with no browser involved, focusing on authorisation enforcement, authentication mechanisms, and data access controls at the API layer. Best practice is to test both together whenever a web front end communicates with a backend API, because the front end generates the requests and the backend enforces the rules. Testing one without the other leaves half the attack surface unexamined.

What does a web application penetration test actually cover?

A web application penetration test covers everything a user interacts with through a browser: rendered HTML, JavaScript execution, form submissions, session management, and client-side storage such as cookies and localStorage.

Testers work through the application as a legitimate user, then step back and manipulate the underlying traffic. Testing follows the OWASP Web Security Testing Guide (WSTG), the recognised methodology for browser-facing application security. Common findings include:

• Cross-site scripting (XSS): Injecting malicious scripts into pages viewed by other users, via reflected, stored, or DOM-based vectors
• Cross-site request forgery (CSRF): Tricking authenticated users into submitting unintended requests from a third-party page
• Clickjacking: Overlaying transparent elements to capture clicks intended for the legitimate UI
• DOM-based attacks: Exploiting JavaScript to alter page behaviour, including prototype pollution in third-party libraries
• Cookie security failures: Missing Secure, HttpOnly, or SameSite flags on session tokens
• Content Security Policy (CSP) bypass: Circumventing headers designed to restrict script execution origins
• Secrets in compiled JavaScript bundles: API keys, OAuth client credentials, or environment variables accidentally included in front-end builds

Testing requires user accounts, a working staging environment, and a role matrix. Testers map the attack surface by walking through every function the application exposes in a browser context.

For a detailed scope breakdown, see our web application penetration testing service.

What does an API penetration test cover?

API penetration testing targets endpoints directly, with no browser in the path. REST, GraphQL, SOAP, and gRPC interfaces are tested by sending crafted requests to the API layer and examining what comes back.

The attack surface is different in kind. The tester interacts with endpoints directly rather than through a browser, even though the API's responses may ultimately render in a UI. Testing maps against the OWASP API Security Top 10 (2023 edition), a separate list from the standard OWASP Top 10 that specifically addresses risks unique to API architectures.

The OWASP API Security Top 10 (2023):

Beyond the OWASP list, API testing covers authentication mechanism specifics that require their own methodology:

JWT testing examines algorithm confusion attacks (setting "alg": "none" to bypass signature verification), RS256-to-HS256 downgrade attacks, injected JWKS URIs pointing to attacker-controlled key stores, weak HS256 secrets vulnerable to offline brute-force, and missing exp claims leaving tokens permanently valid.

OAuth 2.0 testing covers open redirect-based authorisation code interception, missing or predictable state parameters (enabling CSRF against OAuth flows), implicit flow token leakage, and scope escalation.

GraphQL-specific testing adds an additional layer when that architecture is in scope. Enabled introspection exposes the full schema, all types, mutations, and relationships to anyone who sends {__schema{types{name,fields{name}}}}. Batching attacks abuse GraphQL's ability to accept multiple operations per HTTP request: if rate limiting is per-request rather than per-operation, an attacker sends hundreds of login attempts in a single HTTP call and bypasses rate-limit monitoring entirely. Depth attacks use deeply nested queries to force exponential resolver calls, exhausting server resources from a single small payload.

API testing typically requires an OpenAPI or Swagger specification, a Postman collection or equivalent, and valid authentication credentials for each role being tested. If no formal specification exists, testers can work from traffic captures, but this adds time to the reconnaissance phase.

How do web application and API penetration tests compare?

The table below summarises where each test type applies across ten dimensions.

Where the two tests overlap

The distinction is about attack vector, not vulnerability class. Several categories appear on both surfaces:

• Injection flaws: SQL injection and command injection can be triggered through form inputs or API parameters depending on the entry point
• Broken access control: IDOR exists in web apps (manipulating IDs in URL parameters or hidden form fields) and APIs (manipulating resource identifiers in API requests). For more on this category, see our guide to business logic vulnerabilities that scanners miss
• Authentication bypass: Both surfaces can expose weak credential handling, insecure password reset flows, or session fixation
• Security misconfiguration: Permissive headers, exposed debug endpoints, and default credentials are relevant in both contexts

The methodology adjusts to the attack surface; the underlying vulnerability taxonomy is the same.

Why should you test both together?

API calls now account for 57% of all internet traffic, according to Cloudflare's 2024 API Security and Management Report. The majority of applications your users interact with are SPAs communicating with backend APIs, not traditional server-rendered pages.

That shift changes where the risk sits, and why testing both surfaces in a single engagement is the right default.

In a modern SPA built on React, Angular, or Vue, the browser downloads a thin JavaScript client that calls API endpoints for everything: loading data, submitting forms, managing state. The front end constructs and sends requests. The backend validates and processes them. Security depends on both layers working correctly together. A front end that sends a role parameter in a request body is only a problem if the backend trusts it. A backend that returns excessive data is only exploitable if the front end (or an attacker bypassing it) can request it.

At Precursor Security, we test both surfaces in a single engagement when a web front end interacts with a backend API. This reflects how attackers actually work: they use the browser to understand the application, then bypass it entirely to hit the API directly. Testing the front end in isolation misses backend authorisation failures. Testing the API in isolation misses client-side vulnerabilities and the request patterns the front end generates.

A combined approach means the tester:

• Maps how the front end constructs API requests (parameters, headers, tokens, hidden fields)
• Tests whether the backend enforces authorisation when those same requests are replayed or modified outside the browser
• Identifies DOM-based XSS, prototype pollution, and secrets in JavaScript bundles that only exist in the browser context
• Tests BOLA, BFLA, and mass assignment at the API layer using knowledge gained from the front-end reconnaissance

Neither surface tells the full story on its own. Testing them together produces findings that testing them separately cannot.

The T-Mobile breach of January 2023 exposed the personal data of 37 million customers through a poorly configured API with broken access controls. The Trello breach in 2024 exposed 15 million users' account data through an API endpoint that lacked sufficient authentication. Neither would have surfaced in a web application test focused on the browser interface. The Grafana BOLA vulnerability (CVE-2024-1313), found in a product used by over 20 million people, was a classic object-level authorisation failure: an authenticated user could delete another user's snapshot by substituting a resource identifier. That kind of flaw requires direct API testing across account boundaries.

When is a standalone web application pentest sufficient?

A web-only test is appropriate in one specific scenario: the application is fully server-rendered with no separate API layer. WordPress, Drupal, Django template-based apps, and Rails views serving complete HTML pages process business logic in the web layer itself. There is no backend API to test independently.

If the application has any JavaScript front end that calls API endpoints, the default recommendation is to test both.

When does an isolated API pentest make sense?

An API-only test is the right scope when there is no browser front end involved:

• Service-to-service backends. Internal microservices, message queues, and service meshes communicate via APIs with no user-facing interface. These need endpoint-level testing that web application tooling cannot reach. See our cloud penetration testing service for API infrastructure running on cloud-native components.
• Mobile-only backends. An iOS or Android app communicates directly with a backend API. There is no browser surface at all.
• Third-party integration endpoints. B2B data exchange, partner portals, and webhook endpoints are defined API surfaces consumed by external systems, not browsers.

In each case, the API is the entire attack surface for its consumers. There is no front end generating requests that would add additional context to the test.

What does an API penetration test look like in practice?

The phases are worth understanding before you scope the engagement.

Reconnaissance and enumeration: Testers review the API specification (OpenAPI/Swagger), map all endpoints, HTTP methods, parameters, and data types. Where introspection is enabled on GraphQL APIs, this phase can reconstruct the full schema automatically. Shadow endpoints and deprecated API versions are identified at this stage.

Authentication testing: Every authentication mechanism is assessed. JWT testing covers algorithm confusion ("alg": "none" bypass), RS256-to-HS256 downgrade, JWKS URI injection, weak secret brute-force, and missing exp claims. OAuth 2.0 flows are walked through for state parameter weaknesses, open redirect interception, and scope escalation. API key rotation policies and entropy are assessed.

Authorisation testing (BOLA and BFLA): This is typically the highest-yield phase. Testers systematically substitute resource identifiers across accounts to identify whether one user's data can be accessed or modified by another. Function-level testing checks whether standard user tokens can reach admin endpoints by modifying request paths, HTTP methods (e.g., GET vs DELETE), or parameter values.

Input validation and injection: API parameters are tested for SQL injection, command injection, and NoSQL injection. Mass assignment testing submits additional fields not present in the client's normal requests to determine whether the API processes them. Schema enforcement is tested for type coercion, boundary violations, and unexpected content types.

Rate limiting and resource consumption: Endpoints accepting credentials, sending emails, or triggering resource-intensive operations are tested for the absence of rate limiting and throttling controls. GraphQL batching and alias techniques are used to test whether per-operation limits are enforced or just per-request limits.

GraphQL-specific tests (where applicable): Introspection is tested. Batch attacks are constructed. Depth and complexity queries are submitted to test server-side resource controls.

How does a combined engagement work in practice?

A combined engagement is the default for any application where a web front end communicates with a backend API. It is more thorough and more efficient than two separate assessments.

Testers share reconnaissance context across both surfaces: understanding how the front end constructs requests directly informs what to test at the API layer. Overlap areas (injection, access control, misconfiguration) are tested once rather than duplicated across two separate scopes. The result is a single remediation report with coherent risk prioritisation rather than two lists that need cross-referencing.

What to provide when scoping a combined assessment:

• Application URLs and user accounts with each role to be tested (web layer)
• API specification (OpenAPI/Swagger) and a Postman collection (API layer)
• Authentication credentials for each API role (user, admin, read-only, service account)
• Environment URLs for staging (and production access scope, if applicable)
• Rate limit thresholds to avoid unintended denial-of-service conditions during testing
• Any known architectural dependencies between the web front end and the API (shared sessions, token storage mechanism)

For organisations comparing testing approaches more broadly, our guide to SAST vs DAST vs penetration testing covers where manual API testing sits relative to automated scanning, and our OWASP Top 10 guide explains how the web application and API risk lists relate in practice.

Frequently asked questions

Is the OWASP API Security Top 10 different from the OWASP Top 10?

Yes. The OWASP API Security Top 10 and the OWASP Top 10 are separate lists maintained by different OWASP working groups. The OWASP Top 10 addresses web application risks broadly: injection, broken access control, cryptographic failures, insecure design, and similar categories. The API Security Top 10 addresses risks specific to API architectures, particularly how APIs enforce authorisation at the object and function level. Risks like Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) either do not appear in the web application list or are framed differently because the attack mechanics at the API layer are distinct from their browser-facing equivalents. A thorough API assessment maps findings to both lists where relevant.

Does a web application penetration test cover API endpoints?

Partially, but not sufficiently. A web application test conducted against an SPA will observe API calls in the browser proxy and may test some aspects of the API through the browser client. However, it will not systematically test the API layer directly: it will not verify that authorisation is enforced when requests are replayed without the browser client, will not conduct BOLA testing across all resource identifiers, and will not exercise JWT or OAuth mechanisms independently of the browser's handling. This is why combined testing is the recommended approach. The tester uses the front end to understand how requests are constructed, then tests the API directly to verify that backend controls hold up when the browser is removed from the equation.

What is BOLA and why does it matter?

Broken Object Level Authorization (BOLA), also known as IDOR (Insecure Direct Object Reference), is the most prevalent vulnerability in API security assessments and has held the top position on the OWASP API Security Top 10 since 2019. A BOLA vulnerability exists when an API endpoint accepts a resource identifier (such as /api/invoices/1042) and returns or modifies that resource without verifying that the requesting user is authorised to access it. An attacker with a valid account can substitute other users' identifiers to read, modify, or delete their data. The APIsec 2024 API Security Market Report found an average of 1.6 API endpoints at risk of BOLA abuse per organisation. BOLA is difficult to detect with automated scanning because it requires understanding what data belongs to which user and testing across account boundaries, which requires manual testing by a qualified tester.

What documentation do I need for an API penetration test?

The more documentation you provide, the more thorough the test. At minimum, testers need an OpenAPI or Swagger specification covering all in-scope endpoints, a Postman collection showing example requests, authentication credentials for each role being tested (user, admin, read-only, service account), environment URLs for staging, and rate limit thresholds. If a formal specification does not exist, testers can work from traffic captures or manual exploration, but this adds time to the reconnaissance phase. For GraphQL APIs, provide the schema or confirm whether introspection is enabled.

Can API security issues be caught by automated scanning tools?

Automated tools can identify some API security issues: missing rate limiting, verbose error responses, misconfigured CORS, and certain injection patterns are all detectable by scanners. However, BOLA and BFLA, the two most critical categories, require manual testing across account boundaries. A scanner operating with a single set of credentials cannot determine whether User A's requests could return User B's data; that requires deliberately testing across multiple accounts with an understanding of the application's data model. The same limitation applies to JWT algorithm confusion and GraphQL depth attacks, which require crafted payloads rather than pattern matching. Automated tools complement manual API testing; they do not replace it.