API security testing or web application penetration testing: which one first?
Test the API on its own when it is exposed to partners or the internet, shared by several front ends, or carries business logic that the user interface never shows. Test the web application first when user-facing flows and session handling carry most of the risk. Combine both when the same sensitive data flows through the browser and the back end, because the authorization decisions that matter most often sit in the API, where a browser-only test does not reach them. The buyer's compliance question usually turns on whether the back-end API is in scope. PCI SSC guidance says the API may be in scope when a web application uses one, and the tester's understanding of the interaction, exposed functionality and protecting controls helps decide whether it should be tested independently.
The practical trade-off is cost and clarity against coverage. One engagement with a combined scope is simpler to buy, gives one report, and lets the tester chain a front-end weakness into an API call. It also tends to shorten the testing time on each surface, so the API may get less depth than a dedicated test would give. Two engagements give each surface a focused rules of engagement, a tester with the right skills, and findings sorted by their true owner, but they add procurement work and risk gaps where the two scopes meet. Before quoting, ask the provider how it will test object-level and function-level authorization, how it will obtain the API specification and test accounts for each role, and whether the report will map findings to the OWASP API Security Top 10 as well as the web Top 10.
Confirm three things before you decide: whether the API is reachable from outside your network, whether any other client or partner consumes it, and whether your authorization logic lives in the server or the front end. If the answer to the last question is the front end, the API is the first place to test. The OWASP API Security Top 10 2023 is a useful checklist for writing that scope, since its risks, such as broken object level authorization and unrestricted resource consumption, rarely appear in a standard web test plan.
How the two approaches compare on scope, method and outcome
This table compares an API-focused test with a web application penetration test across goals, targets, attacker viewpoint, authentication and what the tester needs from you. Read each row as a scoping question: the right choice depends on whether the back-end API is exposed to clients beyond the web front end.
| Dimension | API security testing | Web application penetration testing |
|---|---|---|
| Primary goal | Find flaws in endpoints, object authorization and business flows that the API exposes to any caller | Find flaws in the application as users reach it through the browser, including the logic that drives the front end |
| Target and scope | Endpoints, methods, schemas and the services behind them, which may be used by mobile apps, partners or other back ends | Web pages, client-side logic and the server functions a user can reach through the interface |
| Typical attacker viewpoint | A caller sending crafted requests directly, without a browser or the front end's controls | A user or attacker operating through the browser, often with the front end's controls in the path |
| Reference risk list | OWASP API Security Top 10 2023, including broken object level and function level authorization | OWASP Top 10 2025, including broken access control, misconfiguration and injection |
| Authentication handling | Tokens, keys and OAuth or OIDC flows are tested per endpoint, and ASVS chapter V10 covers OAuth and OIDC | Session handling and login flows are tested through the browser, which may hide direct token misuse |
| What the tester needs from you | API documentation or an OpenAPI description, schemas, a list of environments and test accounts at more than one role | Application URLs, user roles, test accounts and a description of the business workflows |
| Fit with OWASP and PCI SSC guidance | OWASP WSTG v4.2 includes API testing as one of its 12 web testing categories; PCI SSC says a back-end API may be in scope | PCI SSC treats penetration testing as a manual process, and the web application test covers the functions users reach |
| Scoping decision | Test the API on its own when it serves clients or systems outside the web front end, or when tester understanding shows exposed functions | Test the web application when the front end is the only consumer and the API is covered within that scope |
What API testing finds that web testing misses, and the reverse
API endpoints and the web front end that calls them fail in different places. The OWASP API Security Top 10 2023 concentrates on object, property and function authorization and on resource and workflow abuse, while the OWASP Top 10 2025 focuses on browser-facing controls, misconfiguration and injection. Each card names what one approach finds, where it goes blind, and what to check before you settle on one engagement or two.
Object and function authorization gaps
API1 Broken Object Level Authorization and API5 Broken Function Level Authorization let a caller reach another user's record or an admin action by changing an identifier or HTTP method. The web front end often hides these calls, so a tester working only through the browser may never send the request that exposes them. Ask the tester to run two or more accounts at different privilege levels against every endpoint, and confirm that the scope names the API directly.
Excessive exposure and mass assignment
API3 Broken Object Property Level Authorization covers responses that return more fields than the screen displays, and requests that accept fields the client should never set, such as a role or an account balance. A web test sees only what the page renders, so the extra fields stay invisible. Check the raw JSON responses and write requests for each resource, not only the rendered views.
Unrestricted resource consumption
API4 Unrestricted Resource Consumption describes endpoints that accept unlimited page sizes, batch calls or expensive queries with no quota. Browser-driven tests rarely push request volume or payload size far enough to reach these limits. Ask whether the scope permits load-style probing against non-production copies and whether rate limits are documented for each API tier.
Business flow abuse on the API
API6 Unrestricted Access to Sensitive Business Flows covers sequences such as coupon redemption, account creation or ticket booking that an attacker can script at machine speed. A front end can enforce a sequence that the API itself does not. Testers need the full flow definition and the API calls behind it to judge whether the server enforces the steps.
Client-side logic and browser weaknesses
The OWASP Top 10 2025 places A01 Broken Access Control and A05 Injection at the top, and web tests catch flaws that depend on the browser, such as cross-site scripting, session handling, cookie flags and client-side validation that the page relies on. An API-only test does not run the front-end JavaScript or the browser state. Confirm that the web scope includes authenticated sessions and the browser-side code.
Security misconfiguration outside the API
A02 Security Misconfiguration in the OWASP Top 10 2025 covers headers, CORS settings, error pages and hosting defaults served with the web application. These controls sit between the browser and the API gateway, so an API-only engagement may miss them. Ask the tester whether the edge layer is in scope, and whether the web and API tests share one inventory of hostnames.
How the OWASP API Security Top 10 differs from the OWASP Top 10
The OWASP API Security Top 10 2023 and the OWASP Top 10 2025 overlap less than many teams assume, and that gap decides what a web-front-end test will miss. The API list centers on authorization at the level of individual objects, properties and functions: API1 Broken Object Level Authorization, API3 Broken Object Property Level Authorization and API5 Broken Function Level Authorization. It also covers API2 Broken Authentication, API4 Unrestricted Resource Consumption and API6 Unrestricted Access to Sensitive Business Flows. The web list leads with A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures and A05 Injection. Access control appears on both lists, but the API version breaks it into finer checks that a browser-driven test rarely exercises one by one.
Testing only against the web list leaves gaps because the front end shows a user only the fields and actions the interface offers. An API can return extra properties in a JSON response, accept identifiers the page never sends, or expose a function that no screen calls. A tester working through the rendered application will not see those paths unless someone deliberately requests them. Resource consumption and sensitive business flows, such as bulk export or repeated password reset, are also easy to overlook when the scope is framed as pages and forms. For illustrative purposes, a mobile client may call an endpoint that the web application never uses, and that endpoint may be the one with the weakest object checks.
The OWASP ASVS 5.0.0 gives a verification basis for both sides. Chapter V4 covers API and web service requirements, and chapter V10 covers OAuth and OIDC. Ask the test team which ASVS requirements in those chapters they will verify, and whether token issuance, scope handling and refresh flows are in the statement of work. Confirm also whether the OWASP WSTG v4.2 API testing category is part of the plan, and whether the team will request API schemas and tokens for each role. Those inputs decide whether one engagement can cover both surfaces.
How to decide on one engagement or two
This sequence turns a shortlist of APIs and web front ends into a scoping decision, so the team knows which surfaces each engagement covers and whether one combined scope or two separate scopes fits the architecture. It ends with a documented choice and a shared rules of engagement.
Inventory client types and endpoints
Start by listing every client that reaches the application: browsers, native mobile apps, partner integrations, internal services and scheduled jobs. For each client, record the base URLs, versioned API paths and any undocumented or legacy endpoints found in traffic logs or the gateway configuration. The owner is usually the application lead with the platform team, and the step is done when every client type has a named owner and every endpoint is tied to at least one client. Gaps found here often change the scope more than any later decision.
Map which APIs the web app calls
Trace how the web front end reaches the back end by capturing a browser session through its main workflows, then match each request to an API route. Note which calls originate from the browser, which come from server-side rendering or a backend-for-frontend, and which are made by other services. Keep a simple table of front-end screen, API route and data returned. The step is complete when the team can say which API routes are exercised only through the web UI and which are also reachable without it.
Identify endpoints reachable directly
Test, with the owner's permission, whether each API route accepts requests that do not come from the web application: a direct call with a valid token, a call from a different origin, or a call made with a token issued to another client. Record which routes are reachable directly and what authorization they enforce. This is where object-level and function-level authorization questions, which map to the OWASP API Security Top 10 categories, are first answered. The output is a reachability list that decides whether the API needs its own test target.
Document authentication and token flows
Write down how a user or client obtains, stores, refreshes and revokes credentials at each hop: browser session cookies, bearer tokens, OAuth or OpenID Connect grants, service accounts and API keys. Note where tokens are validated, which claims the back end trusts and whether the front end forwards user tokens or exchanges them. The owner is the identity or platform engineer, and the step is done when the team can draw one diagram per client type showing every token exchange. Ambiguous flows usually point toward a separate API scope, since the web tester and the API tester need to exercise the same token paths.
Decide where protecting controls sit
Determine whether authentication, rate limiting, input validation, web application firewall rules and schema enforcement are enforced at an API gateway, in the application, or in both. Ask the team to show the configuration for each layer and to say which controls exist only in one place. Controls that live only in the gateway may not apply to traffic that bypasses it, so the tester needs to know this before choosing targets. The step closes with a list of each control and the layer that enforces it, which feeds directly into the scope document.
Choose one combined scope or two
Use the earlier findings to pick a model. A single combined engagement suits applications where the web front end and the API share the same authentication, the same routes and the same protecting controls, and where the team wants one report. Two separate scopes suit APIs that are reachable directly, serve other clients, or sit behind different controls than the web app. Under NIST SP 800-115, organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so a combined model with a separate API section is a valid option. Record the decision and the reason for it in writing.
Agree a shared rules of engagement
Whichever model is chosen, write one rules of engagement document covering authorized targets, testing windows, permitted techniques, test accounts, data handling, stop conditions and emergency contacts. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams can adapt. If two scopes are chosen, both testers should sign the same document so that test accounts, rate limits and production safeguards do not conflict. The step is complete when the client signs off, the list of targets matches the reachability map, and every named test account is documented.
What you receive from each engagement
This table compares what each engagement type typically hands back, from OWASP-mapped findings to endpoint inventories and retest scope. Read it to check that the deliverables you need appear in the written scope before work starts, since format and depth are agreed in writing rather than assumed.
| Deliverable | API endpoint test | Web application test |
|---|---|---|
| Findings mapped to OWASP categories | Mapped to API Security Top 10 2023 items such as BOLA and BOPLA, where confirmed | Mapped to OWASP Top 10 2025 items such as broken access control and injection, where confirmed |
| Reproduction steps | Requests, parameters and identifiers needed to replay each call against the API | Browser or client steps, session state and screens needed to replay each flow |
| Endpoint or flow inventory | List of endpoints, methods, schemas and authorization roles tested, often from the supplied specification | Map of pages, user journeys and multi-step business flows exercised |
| Authentication and token coverage | Token issuance, scopes, OAuth and OIDC handling as in scope | Login, session, cookie and password flows as in scope |
| Retest scope | Agreed list of fixed endpoints and roles to retest, stated in the statement of work | Agreed list of fixed pages and flows to retest, stated in the statement of work |
| Rules of engagement record | Target hosts, API environments, test accounts, rate limits and data handling agreed and recorded | Target URLs, test accounts, permitted actions and data handling agreed and recorded |
| Deliverable format and depth | Agreed in the written scope, including report structure and any evidence appendices | Agreed in the written scope, including report structure and any evidence appendices |
| Audit or certification output | Not issued by DeployOpen; confirm with your auditor which evidence they will accept | Not issued by DeployOpen; confirm with your auditor which evidence they will accept |
What drives cost and effort for each approach
Both approaches are priced on the work they require, not on a published rate. DeployOpen does not publish a price list, and a quote follows from written scope, so the cards below name the inputs that move effort up or down for an API test and for a web application penetration test.
Endpoint count and documentation quality
An API test is sized by how many operations, methods and parameters it must exercise, and by whether an accurate OpenAPI or similar specification exists to start from. Without a current specification, testers spend time mapping endpoints that a web front end never shows them. Ask the provider how it will inventory endpoints, whether it will reconcile the specification against live traffic, and whether undocumented routes are in scope.
Authentication models and token handling
OAuth 2.0 and OpenID Connect flows, session tokens, API keys and service-to-service credentials each need their own setup and their own negative tests. ASVS 5.0.0 places API and web service requirements in chapter V4 and OAuth and OIDC in chapter V10, so a team that depends on token flows should expect those controls to take longer to verify. Confirm which token types are in scope and whether the tester needs to inspect the authorization server configuration.
Roles and test accounts
Broken object level and function level authorization, two entries in the OWASP API Security Top 10 2023, can only be confirmed by comparing what each role can reach. Every additional role, tenant or privilege tier multiplies the requests the tester must run and the accounts that must be provisioned and maintained. Ask who creates the accounts, how long they remain valid, and whether service accounts and admin roles are covered.
Environment access and staging parity
Testing against a staging environment that differs from production in gateways, feature flags or data can hide the very authorization gaps being sought. Cost rises when the tester must work around rate limits, synthetic data or a partial copy of production. Confirm which environments are available, how closely they match production configuration, and who approves any test traffic that could affect shared services.
Retest cycles after fixes
Each remediation to an authorization or business logic flaw needs a targeted retest, and API changes often touch several endpoints at once. Retest effort recurs with each release cycle, so a one-time engagement can leave a gap for later versions. PCI SSC guidance notes that a back-end API may be in scope on its own, so ask whether retests are included in the fixed scope or sold as a separate retainer.
How to combine API and web testing without duplicating effort
A combined plan works when the two surfaces share one reconnaissance pass and one authorization test matrix, but report findings separately. Start by mapping every API endpoint the front end calls, including those reached only through single-page application code, mobile clients or partner integrations, and record which roles can reach each one. The same map then drives both sides: the web test checks whether a user can reach a page and its buttons, while the API test checks whether the back end enforces the same decision on each object identifier, property and function. NIST SP 800-115 says organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and this is the practical form of that advice for an application with one front end and one API.
The authorization matrix is where most duplicated effort disappears. Build one table with roles on one axis and resources or functions on the other, then mark each cell as allowed, denied or not applicable for each surface. Testers then exercise a cell once through the browser and once by calling the API directly with the same token, using the API fields named in the OWASP API Security Top 10 2023 such as object identifiers and property filters. A mismatch between the two results is itself a finding, often a broken object level authorization flaw that the UI hides but the endpoint still serves. The OWASP WSTG v4.2 states that no single technique is enough, so keep the matrix as the shared control and do not let either surface quietly skip cells it assumes the other covers.
Keep findings separate even when the root cause is shared. A broken authorization check in a shared service may appear on both surfaces, and the remediation owner may differ, so record one finding per affected surface with a cross-reference. Retest must cover both: after a fix, rerun the affected matrix cells against the API and the front end, and confirm that the controls detecting the test traffic still fire, which aligns with CIS Safeguard 18.4. Confirm with your provider how the retest is priced and whether it is included in the original fixed scope, since that determines whether combining the work actually saves effort.
Questions buyers ask before choosing API or web testing
Does a web application penetration test already cover the API behind it?
Not automatically. A web penetration test follows the front end and the requests it makes, so API endpoints the browser never calls can fall outside what the tester sees. PCI SSC guidance says that when a web application uses a back-end API, the API may be in scope, and the tester's understanding of the interaction, exposed functionality and protecting controls helps decide whether the API should be tested independently. Ask the provider to list every API host and endpoint family in the scope, and to state which ones were reached through the front end and which were tested directly.
What drives the cost and effort of an API test compared with a web test?
The main drivers are the number of endpoints and versions, how authentication and authorization work, and how much the tester must build to reach the API. Cost is mostly tester time, so the size of the API surface matters more than the number of pages. Ask for the endpoint count, the authentication schemes (for example, OAuth and OIDC), the number of roles that need test accounts, and whether an API specification such as OpenAPI is available. OWASP ASVS 5.0.0 covers API and web service requirements in chapter V4 and OAuth and OIDC in chapter V10, which gives a checklist to ask the provider to map against.
How long does preparation take, and what does the team have to provide?
Preparation depends on how quickly your team can supply access, not on the test itself. Before work starts, the tester usually needs an agreed scope, test environments, test accounts for each role, API documentation, rules of engagement and a named contact for questions during testing. NIST SP 800-115 provides a rules of engagement template in Appendix B that you can use as a starting point. Ask the provider to list every item it needs and the date by which each must arrive, because missing test accounts or a staging environment that does not match production are common causes of delay.
Can our own team run an API penetration test in-house?
Your team can run automated API checks in-house, but a penetration test depends on a skilled tester making manual judgments. PCI SSC guidance describes penetration testing as essentially a manual process and says that simply running an automated tool does not satisfy the penetration testing requirement. Access control and business logic flaws, which feature heavily in the OWASP API Security Top 10 (such as API1 Broken Object Level Authorization and API5 Broken Function Level Authorization), usually need a person who understands the intended behavior. If you are assessing your own API for a compliance purpose, check whether the assessor or regulator accepts internal testing and under what independence rules.
Does PCI SSC require a separate test for the back-end API?
PCI SSC does not state that every back-end API needs its own separate test. Its penetration testing guidance says the API may be in scope when a web application uses one, and that the tester's understanding of the interaction, exposed functionality and protecting controls helps decide whether the API should be tested independently. Treat that as a decision you document, not an automatic yes or no. Record which API components sit in the cardholder data environment, how they are reached, and why the chosen testing approach covers them. Confirm the final position with your assessor or acquirer before the engagement starts.
How should we write API testing into a statement of work?
Name the API surface explicitly, not only the application. A useful statement of work lists the API hosts, base paths or specification files in scope, the authentication methods, the roles and test accounts, the environments (production or staging), and the testing approach, whether manual, automated or both. Add the OWASP references the tester should use, such as the OWASP API Security Top 10 2023 for API risks and the OWASP Web Security Testing Guide v4.2 for method. State what is out of scope, including third-party APIs, and how findings are retested. If the engagement is a combined front end and API test, write it as two named scope items so the report can show coverage for each.
Should we buy one engagement or two for the web front end and the API?
Buy one engagement when the front end and API share authentication, data and release cycles, and the team can accept a single report with clearly separated sections. Buy two when the API serves several clients, has its own release cadence, or sits in a compliance boundary that needs an independent test. The deciding factor is coverage: if the API is reachable without the front end, a web test alone will not show its exposure. Ask each provider how it will map findings to the OWASP API Security Top 10 and the OWASP Top 10 2025, so you can compare what each engagement actually tested.
How DeployOpen scopes, delivers and supports API and web security testing
DeployOpen runs security testing as part of work on self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For API security testing vs web application penetration testing, we agree the endpoints, roles, and layers in writing before work starts, so each engagement has a clear boundary and a documented output.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before testing starts.
- We list the API endpoints, front-end flows, user roles and data sets that the written scope covers.
- We record whether an API is tested alone, through the web front end, or both, and why.
How we build
- Testing combines automated checks with manual testing of object-level and function-level authorization.
- We map findings to the OWASP API Security Top 10 or the OWASP Top 10, depending on the scope agreed.
- Test accounts, environments and rules of engagement are confirmed with the client before any requests are sent.
How we hand over
- Each engagement ends with a written report of findings, reproduction steps and affected endpoints or pages.
- Recommendations are tied to specific fixes that your developers can verify in their own environment.
- Retest scope is agreed in writing, so you know which findings were validated after remediation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- A retainer can cover repeat API testing as endpoints change, with its scope set in advance.
- Ask us to confirm how a retainer handles new endpoints, third-party integrations and retesting before you sign.
