attack-surface-test-checklist

Overview

A change set has an attack surface: the set of security-relevant behaviors its files participate in. A migration adding an avatar_url column and one adding a password_reset_token column look identical in a diff stat and need entirely different tests. This skill turns a change set into a bounded security test checklist in four moves:

1. Classify each changed file into one or more of nine attack surfaces.
2. Attach the OWASP ASVS verification requirements for each active surface.
3. Tag each active surface with its OWASP Top 10 2021 category and WSTG test sections.
4. Emit the per-surface manual and automated test items, and list the excluded surfaces.

Differentiation axis

What this owns: the mapping from a specific change to the specific security tests worth running against it, expressed as checkable items with standards references.

What it deliberately is not:

• Not a scanner configuration. The automated items are specifications of what to run, not tool settings. Triaging findings a scanner already produced is a different job.
• Not a penetration-test methodology. WSTG describes a full assessment of a deployed target; this selects a small subset because a change touched a surface, and stops when that surface is covered.
• Not a compliance-control audit. ASVS chapters are a catalog of things worth testing, not controls to attest against. A completed checklist is evidence tests ran, never evidence the change is secure or that any ASVS level is met.

Which ASVS version this uses

All requirement IDs below use OWASP ASVS 4.0.3 numbering. ASVS renumbers requirements between major versions, so an ID with no version attached is ambiguous. ASVS 5.0.0 was released on 2025-05-30 and 4.0.3 remains published as the previous stable release (OWASP ASVS project page). On a project standardized on 5.0.0, treat the chapter names below as the lookup key and re-resolve the numbers against that edition; the surfaces and test items do not change.

ASVS defines three verification levels: Level 1 is a low assurance level that is completely penetration testable, Level 2 is for applications containing sensitive data and is the recommended level for most applications, and Level 3 is for the most critical applications such as those handling high value transactions or sensitive medical data (ASVS 4.0.3, Using the ASVS). For a per-change checklist, default to Level 1 items and escalate to Level 2 when the change touches credential storage or session token issuance. That default is a scoping convention of this skill, not an ASVS rule.

The nine attack surfaces

Classify each changed file by path first, then confirm or correct with content. A file can belong to more than one surface.

Two rules keep the classification honest:

1. Path first, content second. The path signal decides unless file content contradicts it. A file under utils/ that calls yaml.load is a deserialization surface; a file under crypto/ that only re-exports constants is not a cryptography surface.
2. A surface with zero changed lines is excluded, not marked "not applicable". Overscoping is the failure mode that kills these checklists: when every change produces the same forty items, the list stops being read.

Step 1 - Mark the active surfaces

For each changed file, record the surface or surfaces it matched and the count of changed lines attributed to each. A surface is active when at least one changed line lands in it. Keep the file list per surface: it is what makes the test items concrete later ("SQL injection probes on the two new query parameters in orders_controller", not "test for SQL injection"). Record the excluded surfaces explicitly too. A reader needs to see that file upload was considered and found untouched, otherwise they cannot tell whether it was skipped or forgotten.

Step 2 - Attach ASVS requirements

Data protection spans two chapters on purpose. Secrets leaking into logs is a logging requirement (V7.1), not a data protection one, and a checklist that only reads V8 misses it.

Step 3 - Tag Top 10 2021 categories and WSTG sections

Three tagging notes that catch people out:

• XSS is inside A03:2021 Injection. The 2021 category maps 33 CWEs including CWE-79 Cross-site Scripting, CWE-89 SQL Injection, and CWE-78 OS Command Injection (A03:2021). Do not file XSS under a separate category.
• XXE is inside A05:2021 Security Misconfiguration. Its notable CWEs include CWE-611 Improper Restriction of XML External Entity Reference (A05:2021), even though the test that finds it lives in WSTG 4.7 Input Validation.
• WSTG-<CAT>-<NN> shorthand IDs are not printed on the stable index pages. The section numbers used here (4.4.3, 4.5.4, and so on) are what the stable guide publishes, so they are the citable form.

Step 4 - Per-surface test items

Pull only the sections whose surface is active. Rewrite each item with the specific files, parameters, and endpoints recorded in Step 1.

Authentication

Manual:

• Inspect changed credential storage: passwords must be salted and hashed with an approved one-way key derivation or password hashing function (ASVS 4.0.3 2.4.1). If PBKDF2 is used, the iteration count should be as large as verification server performance allows, typically at least 100,000 iterations (2.4.3). If bcrypt is used, the work factor should be as large as performance allows, with a minimum of 10 (2.4.4) (V2).
• Confirm changed login endpoints keep anti-automation controls effective against breached credential testing, brute force, and account lockout attacks; ASVS states no more than 100 failed attempts per hour should be possible on a single account (2.2.1). Pair with WSTG 4.4.3 Testing for Weak Lock Out Mechanism (WSTG 4.4).
• If the change adds an alternative sign-in path, confirm weak authenticators such as SMS and email are limited to secondary verification and transaction approval rather than replacing a stronger method (2.2.2). Pair with WSTG 4.4.10 Testing for Weaker Authentication in Alternative Channel.
• Exercise any changed recovery path: a system generated activation or recovery secret must not be sent in clear text (2.5.1), knowledge-based "secret questions" must not be present (2.5.2), and recovery must not reveal the current password (2.5.3). Pair with WSTG 4.4.9 Testing for Weak Password Change or Reset Functionalities.

Automated:

• Run static-analysis rules for plaintext or reversibly-stored credentials against the changed files only.
• Scan the changed lines for hard-coded credentials and API keys.

The remaining eight surfaces (session management, input handling, file upload, deserialization, access control, API and web service, cryptography, data protection) follow the same Manual / Automated shape with their own ASVS 4.0.3, Top 10 2021, and WSTG citations. Pull the full catalog from references/per-surface-test-items.md.

Output format

Emit one Markdown block containing, in order:

1. Header naming the change set (repository, branch or pull request identifier, and the commit the plan was built from) and the date.
2. Surfaces touched, with the changed-line count per surface.
3. ASVS target level and one sentence saying why that level was chosen.
4. Test items by surface, as checkboxes tagged [MANUAL] or [AUTO], each carrying its ASVS 4.0.3 requirement ID and, where one applies, its WSTG section number. Name the actual files, parameters, or endpoints.
5. Surfaces excluded, listed by name, so a reader can see what was considered and found untouched.
6. Findings already visible in the change, if any: something spotted while classifying that is a defect now, not a test to run later.
7. Not established by this checklist: an explicit line stating that completing the items is evidence tests ran, not evidence the change is secure, and not an ASVS level attestation.

Keep item 7 even when it feels redundant. It is what stops a green checklist from being read as a sign-off.

Worked example

Change set: a pull request on a document management service adding shared-link downloads. Changed files:

src/api/routes/share_links.py          +142
src/services/share_link_service.py     +96
src/storage/attachment_fetcher.py      +54
src/models/share_link.py               +31
migrations/0042_share_link.sql         +18
tests/api/test_share_links.py          +210

Classification: api/routes/ and the new query parameters make input handling and API and web service active. storage/ plus a fetch by URL makes file upload active (its SSRF sub-area specifically). The model and migration add a token column, making data protection active. share_link tokens are generated in the service, making cryptography active. The link grants object access without a session, making access control active. No login, cookie, or deserialization code changed. Test files are excluded from classification.

## Security test plan - docs-service PR #814 - 3f9a1c2

**Surfaces touched:** input handling (142), API and web service (142),
access control (96), file upload / SSRF (54), data protection (49),
cryptography (96)
**ASVS target level:** L2 (the change issues a bearer-style access token)
**Produced:** 2026-07-19

### Input handling
- [ ] [MANUAL] SQL metacharacters on `?token=` and `?expires=` in `share_links.py`; confirm parameterized queries (ASVS 4.0.3 5.3.4; WSTG 4.7.5)
- [ ] [MANUAL] Positive allow-list validation on both new parameters (ASVS 4.0.3 5.1.3)
- [ ] [AUTO]   Injection static-analysis rules scoped to `src/api/routes/`

### API and web service
- [ ] [MANUAL] Verb tampering on `/share/{id}`: PUT, DELETE, PATCH (ASVS 4.0.3 13.2.1; WSTG 4.7.3)
- [ ] [MANUAL] Wrong and missing `Content-Type` rejected (ASVS 4.0.3 13.2.5, 13.1.5)
- [ ] [MANUAL] `token` is not exposed in the URL path or logs (ASVS 4.0.3 13.1.3)

### Access control
- [ ] [MANUAL] Fetch another tenant's document id with a valid token (ASVS 4.0.3 4.2.1; WSTG 4.5.4)
- [ ] [MANUAL] Force an exception in the token guard; confirm deny (ASVS 4.0.3 4.1.5)

### File upload / SSRF
- [ ] [MANUAL] `attachment_fetcher.py` remote fetch against 169.254.169.254 and file:// ; confirm allow list (ASVS 4.0.3 12.6.1; A10:2021)

### Cryptography
- [ ] [MANUAL] Token generated via CSPRNG, not `random` (ASVS 4.0.3 6.3.1)
- [ ] [AUTO]   Flag `Math.random` / `random.random` in `share_link_service.py`

### Data protection
- [ ] [MANUAL] Token column encrypted or stored hashed (ASVS 4.0.3 8.3.7)
- [ ] [MANUAL] No token value in the new log lines (ASVS 4.0.3 7.1.1)

### Surfaces excluded (no changed lines)
Authentication, session management, deserialization

### Findings already visible in the change
- `share_link_service.py:41` builds the token with `random.randint`. This is a defect now, not a test item. Route it to defect triage.

### Not established by this checklist
Completing these items is evidence that the listed tests ran against this change. It is not a statement that the change is secure, and it is not an ASVS L2 attestation.

Anti-patterns

Limitations

• Path classification is a heuristic. A shared utility in the change set can reach an authentication flow that no path signal touched. Content signals reduce this but do not remove it; a short human read of the change set is still warranted.
• The level default is conservative. The Level 1 default, escalating to Level 2 for credential storage or session token issuance (defined in "Which ASVS version this uses"), suits most changes; teams in regulated or safety-critical domains should raise it rather than accept Level 1.
• No threat model. Surfaces map to known categories. Attacker motivation, likelihood, and business impact are not modeled, so the checklist cannot rank its own items by risk.
• No dynamic analysis is performed. The [AUTO] items are specifications of what to run. Something else has to run them.
• Requirement IDs are version-bound. Every ID here is ASVS 4.0.3. On a project standardized on 5.0.0 the chapter names still route correctly but the numbers must be re-resolved against that edition (OWASP ASVS project page).
• WSTG shorthand IDs are not used. The stable guide's index pages publish section numbers, not WSTG-<CAT>-<NN> identifiers, so section numbers are what this skill cites.

Source index

Every requirement ID, section number, and quoted phrase above carries its source link at the point it is used. These are the three roots those links come from, for anyone who wants to browse rather than verify one claim:

• OWASP ASVS 4.0.3 chapter index: chapters V2 through V13, the source of every ASVS 4.0.3 <n.n.n> ID here.
• OWASP Top 10 2021: category pages A01 through A10.
• OWASP WSTG stable table of contents: section 4 test areas 4.1 through 4.12, the source of every 4.x.y number.