# Web and API checks

Original security-pentest guidance; see [provenance](../THIRD_PARTY_NOTICES.md).
Choose checks from observed surfaces. The test oracle is the application's
intended security boundary, not a checklist keyword or response code.

## Identity, objects and fields

Create an identity/action/object matrix from supplied test accounts. Include
anonymous, owner, peer, other organization and privileged roles where available.
Establish legitimate access, then substitute a known disposable object or session.
Cover list/detail, edit, delete, search, bulk operations, exports, files and jobs.
Check permissions after sharing, revocation, membership and role changes. An
unavailable second account blocks that comparison; do not invent its result.

Inspect complete API responses for forbidden fields. Change client-controlled
ownership, organization, role, price or approval fields only on test records;
verify persisted state and subsequent access. A 200 response to an ignored field
is not mass assignment. UI restrictions and unpredictable identifiers do not
establish backend authorization. With source, trace shared guards and storage
policies before concluding that a route-local check is missing.

For authentication, test registration, invitations, recovery, email/identity
changes, MFA completion, session rotation, logout and expiration. Check binding
to the intended account/session/action, replay and revocation against documented
product policy. Use permitted test inboxes and finite attempt counts. Do not
report lack of a rate-limit response after a few requests as proven unlimited
guessing. Distinguish access-token lifetime policy from broken session revocation.

When deeper procedures are needed, consult [OWASP object authorization](https://owasp.github.io/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/),
[property authorization](https://owasp.github.io/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/)
or [session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).

## Untrusted input and the browser

Trace input into queries, commands, templates, markup and DOM operations. Use
small, context-specific probes with a baseline; confirm interpretation or an
observable security effect without dumping databases or executing destructive
commands. An exception or isolated timing difference is only a lead. Account for
parameter binding, escaping and downstream validation in the actual path.

For XSS, distinguish reflection from execution and self-only behavior from an
attacker-to-victim path. Use a harmless local signal in a controlled test browser,
not credential collection. Include persisted content and alternative renderers
when they exist. Without browser execution, label runtime confirmation unavailable.

For CSRF/CORS, reproduce the relevant cross-origin behavior in a browser with
the actual authentication mechanism. Test whether a forbidden action occurs or
protected content becomes readable; forged Origin headers alone are insufficient.
Wildcard access to intentionally public data, absent security headers, enabled
GraphQL introspection and an open redirect alone are not automatically impactful
vulnerabilities. Show the applicable trust boundary or record a hardening note.

Use [PortSwigger XSS](https://portswigger.net/web-security/cross-site-scripting)
or [CSRF](https://portswigger.net/web-security/csrf) guidance when that surface
requires additional context; verify implementation-specific protections separately.

## Business state, data exposure and failure paths

Write the invariant before testing: for example, only the owner can export a
private document, or a fulfilled order must have a verified payment. Exercise
skipped steps, replay and altered values with disposable data. Compare final
state, not just HTTP responses. Ask about genuinely ambiguous business rules
instead of declaring permitted behavior a vulnerability.

Inspect observed deployment/configuration surfaces for public private-data
storage, debug output, unintended administrative access, insecure transport and
secret exposure. Public client identifiers and source maps require context;
classify a credential's role and exposure without printing or using its value.
With source, inspect resolved dependencies and reachable affected paths against
current advisories. A banner or unverified version match remains a lead.

Use bounded malformed inputs and test-environment fault simulation to examine
fail-open behavior, rollback and safe errors. Check operation and spending limits
by inspection and small tests; resource exhaustion is not a default technique.
When logs are available, verify the tested events are attributable and redacted.
Lack of log access is a coverage gap, not evidence that logging is absent.