Web Assessment Coverage

Web assessment coverage

A web assessment is complete only when every discovered surface has an honest disposition. A route inventory is not coverage, and a planned test is not a negative result.

Use this skill only inside written authorization. Scope, rate, impact, test accounts, and permission for state changes come from the engagement, not from this skill.

When to Use

• Planning, conducting, reviewing, or handing over an authorized web or API penetration test.
• Use only within explicit authorization and the stated rules of engagement.

When NOT to Use

• Do not treat this skill as permission to access, test, or change a target.
• Do not convert missing evidence into a clean result or a stronger claim.

Build the coverage ledger

1. Record the assessment boundary. State the exact in-scope origins, engagement type, available identities, action classes allowed now, request limits, excluded systems, and handling constraints. Stop at out-of-scope redirects and resource hosts.
2. Inventory surfaces before testing. Record every observed route, method, input, authentication state, API operation, GraphQL operation, WebSocket, upload, business workflow, client-side surface, and configuration surface. Preserve distinct methods and trust contexts as distinct surfaces.
3. Derive required families. require:
   • any surface with input: injection;
   • authentication surface: authentication and session-management;
   • API: api; GraphQL: api and graphql;
   • upload, WebSocket, business logic, client side, and configuration: their matching test family;
   • ownership-sensitive surface: horizontal-access-control role checks;
   • privilege boundary: vertical-access-control role checks.
4. Name access-control pairs. For horizontal checks, identify the actor and peer resource owner, including the reverse direction when both matter. For vertical checks, identify the lower-privilege actor and privileged target. An unavailable administrator account limits what can be concluded; it does not make vertical coverage complete.
5. Give each required case one status. Use planned, executed, blocked, or not-applicable. Blocked cases name the blocker. Not-applicable cases explain why the family does not apply. Planned cases remain untested.
6. Separate status from outcome. Only an executed case can report finding, no-issue, or inconclusive, and every executed case links to evidence. Every other status uses not-run.
7. Enforce authorization per case. Classify the action as read-only, authenticated read, reversible state change, state change, active execution, high volume, or external contact. Work outside the currently allowed classes is marked requires-separate-approval; never present it as executable now.
8. Summarize by family without hiding gaps. Each family summary references all of its coverage records. derive the claim:
   • any evidenced finding → finding;
   • any planned or blocked case → incomplete;
   • otherwise any inconclusive execution → inconclusive;
   • fully executed cases with no findings → no-issue;
   • all cases justified as not applicable → not-applicable.
9. Send confirmed vulnerabilities to the reporting skill. Coverage says what was tested. A finding still needs reproducibility, impact, severity, and remediation.

Test depth follows the engagement

• Completeness does not mean maximum impact. Cover a high-impact family with a blocked or approval-gated record when safe validation is unavailable.
• Use known fixtures for authorization. Comparing two supplied accounts is evidence; enumerating other customers is scope expansion.
• State changes need recovery. Define the exact mutation, expected artifact, restoration action, and maximum attempts before seeking approval.
• Negative bounded tests have limits. A small race or rate sample may find a flaw, but silence does not establish resilience against higher volume.
• Third-party services remain separate targets. Record an external redirect, storage URL, mail system, or payment processor without touching it unless its origin is explicitly in scope.

Judgment calls

The script derives required families from the normalized surface fields and checks the evidence contract. It cannot decide whether the route inventory is complete, whether a payload was technically adequate, or whether linked evidence proves the claimed security behavior. Review those judgments directly.

Rationalizations to reject