Generate a Security Test Checklist Aligned with OWASP ASVS
Returns an OWASP ASVS-aligned security testing checklist covering authentication, session management, authorization, input validation, output encoding, cryptography, API security, file upload, and HTTP security headers — each item with a test method (manual / DAST / SAST) and ASVS chapter citation.
When to use it
- You're preparing for a pen test and want a self-audit first.
- You're documenting security testing scope for SOC 2 / ISO 27001.
- You're onboarding security testing into a team without an AppSec hire.
- You're standardizing security checks across multiple services.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are an application security tester. You cite OWASP ASVS chapters because security work without citations is unverifiable. You pair every checklist item with a TEST METHOD (manual / DAST / SAST) so the reader knows how to actually run it.
</role>
<context>
OWASP ASVS (Application Security Verification Standard) is the canonical security checklist. Three levels: L1 (minimum), L2 (most apps), L3 (high-assurance). For each app component, the checklist covers: V2 Authentication, V3 Session, V4 Access Control, V5 Validation/Sanitization, V6 Crypto, V7 Logging, V8 Data Protection, V9 Communication, V10 Malicious Code, V11 Business Logic, V12 Files, V13 API, V14 Configuration.
</context>
<task>
For the application below, generate a security testing checklist with:
1. Items grouped by ASVS chapter (V2-V14, scoped to what applies)
2. ASVS chapter cited in every item (e.g., "V2.1.5")
3. Test method per item: **Manual** (requires human judgment) / **DAST** (dynamic scan tool) / **SAST** (code analysis) / **Manual+DAST** (both)
4. Severity if violated (Critical / Major / Minor) — tied to compliance frameworks
5. Group ordered: highest-risk chapters (V2, V4, V8) first
</task>
<input>
Application description: {app}
Tech stack: {stack}
Compliance requirements (SOC 2, HIPAA, PCI DSS, etc.): {compliance}
ASVS level target (L1, L2, L3): {level}
</input>
<constraints>
- Cite ASVS chapter and item number for every entry (e.g., V2.1.5).
- Test method MUST be present per item.
- Don't list items that don't apply to the stated app (e.g., file upload section is skipped if no uploads).
- Group by ASVS chapter, ordered by risk priority for this app.
- Highest-risk first; don't bury auth on page 5.
</constraints>
<output_format>
Markdown document with chapter headings, each chapter contains a table: ASVS | Item | Test method | Severity. Followed by "Coverage summary" — how many items, which chapters are out of scope and why.
</output_format>
Before writing, identify which ASVS chapters are most acute for this stack and compliance context.Example
Common pitfalls
- Model produces generic security checklist (Top 10 style) without ASVS citations — explicit V2.1.5 references make it auditable.
- Test method column gets omitted — checklist becomes 'check this somehow' instead of actionable.
- Items lumped into one big list without chapter grouping — harder to delegate by domain.
- Severity defaults to 'High' for everything — meaningless. Force Critical/Major/Minor with reasoning.
Tips
- Re-run when ASVS publishes a new version (yearly); items get added/refined.
- Map each item to your bug tracker AS a ticket — checklist that doesn't become tickets is wallpaper.
- Pair with `owasp-top-10-scenarios` for the dynamic test scenarios; this prompt produces the inventory.
- Pair with `sbom-dependency-tests` to fill V10 Malicious Code and V14.5.1 Dependencies coverage.
FAQ
L1: minimum baseline, ~120 items. L2: most apps that handle data, ~270 items. L3: critical apps (banking, health), ~290 items. Most B2B SaaS targets L2. Don't aim for L3 unless your compliance regime requires it.
Related prompts
Create OWASP Top 10 Test Scenarios
For each OWASP Top 10 (2025) category (A01-A10), returns 3-5 concrete test cases with payloads, recommended tools, expected secure behavior, and remediation guidance tailored to the target application.
Open →Generate Authentication Bypass Test Cases
Returns a structured suite of authentication and authorization bypass test cases — IDOR, JWT algorithm confusion, session fixation, MFA bypass, brute-force resistance, broken object-level authz — with payloads, CWE numbers, and the detection signal that confirms vulnerability vs secure behavior.
Open →Generate API Rate Limiting Test Scenarios
Returns rate-limiting test cases verifying X-RateLimit-* headers, behavior at the limit boundary, burst handling, reset window semantics, per-authentication-level limits, and concurrent request behavior across multiple workers.
Open →SBOM-Based Dependency Vulnerability Tests
Reads an SBOM (CycloneDX or SPDX) and returns test cases for known-vulnerability presence (CVE lookup against KEV catalog), license compliance (allow/deny list), transitive dependency drift, and prioritized update list based on exploitability and reach.
Open →