# Web & API pentesting

Canonical: https://www.web3sec.news/services/web-api-pentesting
Provider: Raiders (https://www.web3sec.news/about)

Follow the attack paths between identities, application workflows, APIs, and the systems they can reach.

## Who this is for

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.

### Diagram: Authorization belongs at the resource boundary.

Authenticate the caller, then evaluate what this caller may do to this resource.

![An authenticated principal requests an object and action. The server checks object ownership or tenant, permitted action, and current business state before accessing the scoped resource. A client-supplied identifier is input, not permission.](https://www.web3sec.news/diagrams/api-authorization-boundary.svg)

[Full-size SVG](https://www.web3sec.news/diagrams/api-authorization-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/api-authorization-boundary.png)

Original explanatory control model; not a reconstruction of private incident evidence.

## Outcomes

- 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.

## Scope

- 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.

## Process

### 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.

## Illustrative deliverables

These describe possible work products, not past client findings or promised outcomes.

### 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.

## Boundaries

- 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.

## 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.

[Discuss this work](https://www.web3sec.news/contact) · [Approach](https://www.web3sec.news/approach)