Web Application Security Testing Checklist (2026)

This is the checklist we run on every web application security test. Not theory. What actually breaks, in the order we test it.

Auth and sessions

1. Session fixation — can an attacker force a session ID before login and reuse it after?
2. Token handling — are JWTs validated on expiry, signature, and audience, or just decoded?
3. Privilege escalation — can a regular user reach admin routes by guessing the URL?
4. Password reset — is the reset token single-use, short-lived, and bound to the account?

Access control

1. Tenant isolation — does every query scope to the caller's organization, or can you read another tenant's data by changing the ID?
2. Object-level auth — is `GET /api/orders/123` authorized per-object, or just per-route?
3. Horizontal escalation — can User A read User B's invoices, orders, or profile by swapping IDs?
4. Vertical escalation — can a member call owner-only endpoints (delete org, manage billing)?

Injection

1. SQL injection — string concatenation in queries, ORM misuse, raw SQL paths.
2. Command injection — is user input passed to shell commands, file paths, or template engines?
3. Header injection — can you poison Host, X-Forwarded-For, or Referer to bypass logic?
4. Template injection — are user-supplied strings evaluated as template code?

Business logic

1. Workflow abuse — can you skip steps in a multi-step flow (checkout, approval, onboarding)?
2. Race conditions — do concurrent requests let you double-spend, over-draw, or over-allocate?
3. Rate limits — are login, password reset, and OTP endpoints rate-limited?
4. Abuse of trust — does the app trust client-side values (price, role, tenant) it should verify?

API and surface

1. Shadow endpoints — are there routes in the code that are not in the docs, still reachable?
2. Debug routes — is `/debug`, `/metrics`, or `/health` exposing stack traces or internals?
3. Exposed secrets — are keys, tokens, or passwords readable in the shipped JavaScript bundle?
4. CORS — is Access-Control-Allow-Origin set to `*` with credentials enabled?

Dependencies and config

1. Vulnerable packages — are dependencies with known CVEs still reachable in production?
2. Static files — is `.env`, `.git`, or config served as a static file?
3. Defaults — are default credentials, debug mode, or admin panels still enabled?
4. Error handling — do stack traces leak SQL, file paths, or secrets in the response?

The fix

Every item above gets tested live, not scanned. A failed check means the issue was proven, with the exact request that worked and the one change that closes it.

Muster runs this checklist continuously on every deploy, not once a year. Start free, first findings in ~10 minutes.