Direct answer
Choose the assessment scope around the assets and trust boundaries you need to evaluate. A web review can cover browser-facing flows and sessions; an API review focuses on exposed operations and their authorization. Most modern applications need an agreed combination of both.
Map the application before choosing a label
List the browser application, mobile clients, APIs, administration interfaces and third-party services that support the feature. Mark which are owned by your organization, which environments may be tested and which components are outside the engagement.
A browser application may call the same API used by a mobile client. Testing only visible browser pages can miss routes or permissions that are not reached through that interface.
Reference: OWASP Web Security Testing Guide.
Choose tests based on the risk
A web-focused review can examine browser rendering, session handling, login, user journeys and security-relevant application logic. An API-focused review can examine request and response handling, object and function authorization, token use, rate controls and endpoint inventory. The two overlap on authentication and authorization.
If a customer portal lets users download invoices through an API, include both the browser download flow and the underlying API operation. Give the tester two isolated accounts with separately owned test invoices so that allowed and denied access can be compared.
Reference: OWASP API Security Top 10: Broken Object Level Authorization.
Supply practical assessment inputs
Prepare test URLs, API documentation or an OpenAPI definition if available, a role and permissions matrix, and test accounts for each role and tenant. Include representative safe test records and explain expected access, including support users and shared objects.
Identify integrations that send email, charge a card or affect external systems. Agree whether they use test modes and what actions are excluded before testing starts.
- List each in-scope host, API version and environment, plus exclusions.
- Provide role-specific accounts and written expected permissions.
- Agree on test windows, rate limits, contacts and evidence handling.
Agree on coverage and outputs
Ask for a coverage record showing which journeys, API routes and roles were tested and what could not be tested. Findings should include enough sanitized evidence to reproduce the issue, impact in context and a proposed remediation.
Plan a retest of agreed fixes with the same test accounts and include positive cases to confirm that legitimate access still works. A report is a snapshot of the agreed scope and conditions.
Reference: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
Assessment limits
Names such as web pentest and API pentest do not guarantee a fixed set of tests. Coverage depends on agreed scope, time, accessible routes, accounts and test data. Neither assessment alone establishes that all infrastructure or business logic is secure.
Frequently asked questions
Does a web application pentest automatically cover every API?
No. The scope should name API versions, routes, clients and roles. An endpoint not reached by the tested browser flows may need separate coverage.
Can an API assessment test access between customers?
Yes, if the agreement includes that boundary and suitable isolated test accounts, records and expected permission rules are provided.
Is an automated scan a substitute for all manual testing?
Automation can support defined checks, but business logic and intended permission decisions often require context and manual review.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.
This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.