Expertise / 02
Web & API pentesting
Follow the attack paths between identities, application workflows, APIs, and the systems they can reach.
Authenticate the caller, then evaluate what this caller may do to this resource.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Who this is for
A clear question.
A useful outcome.
Product and engineering teams shipping a web application, exposing an API, introducing a new role, or changing a sensitive business workflow.
The most important application weakness may be a valid request made by the wrong person at the wrong moment. Testing therefore follows how the product actually works: account creation, invitations, organization membership, permissions, billing, exports, administrative actions, and integrations. The aim is to establish whether one user can cross a boundary that the system promises to enforce. Findings connect technical behavior to specific data, capabilities, or business outcomes rather than reporting scanner output without context.
What you should leave with
- Identify practical ways to cross user, tenant, role, or workflow boundaries within the authorized test environment.
- Give developers reproducible evidence and a clear explanation of the server-side checks that need to change.
- Help the release owner distinguish confirmed weaknesses from assumptions that require more testing or a separate specialist review.
Review boundary
What the work can cover.
Authentication and sessions
recovery, invitation flows, token lifecycle, sensitive account changes, and differences between browser and API behavior.
Authorization
object access, tenant separation, administrative functions, bulk operations, exports, and capabilities available through alternate endpoints.
Business logic
workflow ordering, state changes, replay, concurrency, entitlement enforcement, and interactions between individually valid features.
Input and integration boundaries
injection, unsafe rendering, file handling, webhook validation, external requests, error exposure, and relevant deployment configuration.
From context to evidence
How the engagement works.
Authorize the work
Agree on exact hosts, APIs, environments, dates, permitted techniques, test accounts, excluded systems, and an emergency stop contact. Provide API documentation, user-role descriptions, architecture context, and a way to create representative test data.
Exercise realistic paths
Map the accessible application and compare requests across accounts and roles. Test server behavior directly rather than assuming that a hidden button is protected. Use scanners to support coverage, then validate relevant results and explore chained behavior manually.
Explain, repair, and retest
Report affected requests, prerequisites, observed behavior, and potential impact with sensitive evidence minimized. Discuss fixes at the authorization or workflow boundary. Where agreed, retest the changed build and record what remains open.
Concrete outputs
Deliverables you can use.
Examples below are illustrative. They describe possible work products, not past client findings or promised results.
Coverage and boundary record
A clear inventory of tested roles, routes, workflows, and important exclusions. Illustrative example: customer and organization-admin accounts tested against tenant exports and membership changes.
Reproduction-led report
Prioritized findings with sanitized request sequences and remediation guidance. Illustrative example: a user can retrieve another tenant’s export by changing an identifier despite a restricted interface.
Retest summary
A finding-by-finding status linked to the tested build, explaining whether the original attack path and relevant alternate paths were checked.
Scope and responsibility
Boundaries worth agreeing early.
- Testing requires written authorization from the system owner. Third-party providers, employee devices, and customer-controlled tenants are excluded unless explicitly authorized.
- Denial of service, destructive actions, social engineering, persistence, and large-volume data access are excluded by default and require a separate agreement if appropriate.
- A bounded pentest provides evidence about its scope and time window. It does not replace secure development, continuous monitoring, or a compliance certification.
Before sharing code, customer information, or incident artifacts, agree on confidentiality and a private transfer channel. Keep the initial message high level.
Before we begin
Common questions.
Can testing happen in production?
A representative staging environment is often the best starting point. Any production testing needs explicit limits, approved accounts and data, a stop process, and agreement on how to avoid disrupting real users.
Do you need source code?
A source-assisted review can explain trust boundaries and improve depth. A black-box or authenticated test is also possible; the access model and its coverage limits should be explicit in the proposal.
Can you help engineers understand the fixes?
Yes, remediation discussion and a defined retest can be included. The useful outcome is a change to the underlying control, supported by regression coverage, rather than blocking one demonstrated request.
Go a little deeper
Practical reading.
Connected work
Related services.
Smart contract security
Challenge the assumptions, permissions, and economic edge cases in the code that moves value.
Explore this service →03Incident readiness & response
Prepare the decisions, access, and evidence your team will need when normal assumptions stop holding.
Explore this service →04AI & supply-chain security
Examine what your agents can act on, what your build trusts, and how untrusted input can reach a privileged action.
Explore this service →