/auth-audit — Custom Auth Security Audit
Security audit for custom auth implementations with bcryptjs/argon2 + session-based authentication. Checks against OWASP ASVS v4.0.3 (V2: Authentication, V3: Session Management).
Scope: Custom auth — NO NextAuth, Lucia, Auth.js, or external OAuth provider. Focus on self-built registration, login, sessions, password reset.
Complementary to /audit: This skill checks auth-specific security. The generic /audit checks code quality, performance, SEO, a11y, etc.
Modes
Detect the mode from user input:
- start -> Mode 1 (Scan project, detect auth stack)
- continue -> Mode 2 (Process next areas/fixes)
- status -> Mode 3 (Show progress)
- report -> Mode 4 (Structured Markdown report)
- auto -> Mode 5 (Fully autonomous run)
Mode 1: /auth-audit start — Scan Project
Auto-Detection (in this order)
- package.json -> Auth-relevant dependencies:
- Hashing:
bcryptjs, bcrypt, argon2, @oslojs/crypto
- Tokens:
jose, jsonwebtoken, paseto
- Sessions:
express-session, iron-session, cookie, @sveltejs/kit (built-in cookies)
- Validation:
zod, valibot (for auth input)
- Rate limiting:
rate-limiter-flexible, express-rate-limit
- Framework detection:
- SvelteKit:
src/hooks.server.ts with auth logic, +page.server.ts with form actions
- Express/Fastify: Middleware files, route guards
- Astro:
middleware.ts, API routes under src/pages/api/
- Search for auth files:
**/auth/**, **/login/**, **/register/**, **/session/****/middleware.*, **/guard.*, **/protect.***/*auth*.*, **/*session*.*, **/*password*.*
- Database schema:
- Drizzle:
schema.ts / schema/*.ts -> Users table, Sessions table
- Prisma:
schema.prisma -> User/Session models
- Raw SQL:
*.sql migration files
- Environment:
.env, .env.example -> Auth-relevant secrets (SESSION_SECRET, JWT_SECRET, etc.)
Flow After Detection
- Display result table: Framework, hashing lib, session type, DB schema, rate limiter
- [CHECKPOINT: decision] Confirm framework + auth approach
- Prioritize areas by severity order (max 2 per session)
- Check each checkpoint against the project (cite OWASP ASVS reference)
- Save findings to
.auth-audit-state.json
- Display summary + prioritized list
- Session end: "Start next session with
/auth-audit continue"
Mode 2: /auth-audit continue — Resume
- Read
.auth-audit-state.json
- Generate smart recommendation:
IF open CRITICAL findings > 0:
-> "Recommendation: Fix {N} CRITICAL findings first ({IDs})"
IF open HIGH findings > 3:
-> "Recommendation: Fix HIGH findings, then continue"
ELSE IF areas open:
-> "Recommendation: Next areas ({area names})"
ELSE:
-> "Recommendation: Fix remaining findings"
- If areas open -> process next 2 areas
- If all areas done -> next 5 findings by priority
- Load fix templates (from
fix-templates.md) where applicable
- Ask user: Follow recommendation? Choose different? Skip?
- Implement fixes -> verify -> update state
Mode 3: /auth-audit status — Progress
- Read
.auth-audit-state.json
- Display table: Done/Open/Total per area + severity
- Show OWASP coverage (V2/V3 sections)
- Next recommended action
Mode 4: /auth-audit report — Markdown Report
Generate a structured Markdown report.
- Read state file
- Group all findings by area
- Report with executive summary, findings per area, OWASP coverage, recommendations
- Insert trend analysis (if history available):
Trend (recent audits):
CRITICAL: 3 -> 1 -> 0 (resolved)
HIGH: 5 -> 3 -> 2 (declining)
Total: 12 -> 8 -> 5
Assessment: Project is steadily improving.
- Save report as
AUTH-AUDIT-REPORT-{YYYY-MM-DD}.md in project root
- If previous reports exist: Diff section (new/resolved since last report)
Mode 5: /auth-audit auto — Autonomous Run
Fully autonomous auth audit without prompts.
Flow
- Auto-detection as in
start
- All areas processed (no 2-area limitation)
- Document findings with fix templates from
fix-templates.md
- Context management: When context runs low:
- Write state immediately
- Create task in
.tasks.json with handoff note
- "New session with
/auth-audit continue"
- At end: Summary with prioritized fix list
Severity Order of Areas in Auto Mode
CRITICAL areas first:
HASH -> SESS -> CSRF -> COOK -> STORE -> LOGIN -> REG -> RESET -> AUTHZ -> LOG
Areas
HASH — Password Hashing
OWASP ASVS: V2.4 (Credential Storage)
| Check |
Priority |
Description |
| Hashing algorithm |
[MUST] |
bcryptjs or argon2 (NOT md5, sha256, scrypt without config) |
| bcrypt rounds |
[MUST] |
Minimum 10 rounds, recommended 12 (ASVS 2.4.4) |
| Salt handling |
[MUST] |
bcryptjs.genSalt() or auto-salt via bcryptjs.hash(pw, rounds) |
| Timing-safe compare |
[MUST] |
Use bcryptjs.compare(), NEVER === on hashes |
| Pepper |
[CAN] |
HMAC pepper before hashing (server-side secret) |
SESS — Session Management
OWASP ASVS: V3.1-V3.7 (Session Management)
| Check |
Priority |
Description |
| Session ID entropy |
[MUST] |
Min. 128-bit random value (crypto.randomUUID or @oslojs/crypto) |
| Session expiry |
[MUST] |
Absolute + idle timeout set (ASVS 3.3.1) |
| Session rotation |
[MUST] |
New session ID after login (ASVS 3.3.2 — session fixation prevention) |
| Session invalidation |
[MUST] |
Logout deletes server-side + cookie (ASVS 3.3.1) |
| Server-side storage |
[MUST] |
Sessions in DB, not client-cookie only (ASVS 3.2.1) |
| Concurrent sessions |
[SHOULD] |
Limit or display of active sessions |
CSRF — CSRF Protection
OWASP ASVS: V4.2.2 (Anti-CSRF)
| Check |
Priority |
Description |
| SvelteKit origin check |
[MUST] |
Automatically active — NOT disabled (csrf.checkOrigin: false) |
| State-changing GET |
[MUST] |
No state changes via GET requests |
| Custom token |
[SHOULD] |
Double-submit cookie or synchronizer token for APIs |
| Fetch requests |
[SHOULD] |
Custom header (X-Requested-With) on AJAX calls |
COOK — Cookie Security
OWASP ASVS: V3.4 (Cookie-based Session Management)
| Check |
Priority |
Description |
| httpOnly |
[MUST] |
Session cookie httpOnly: true (ASVS 3.4.2) |
| secure |
[MUST] |
secure: true in production (ASVS 3.4.1) |
| sameSite |
[MUST] |
sameSite: 'lax' or 'strict' (ASVS 3.4.3) |
| path |
[SHOULD] |
path: '/' (or more restrictive) |
| maxAge |
[MUST] |
Reasonable maxAge set (not unlimited) |
| domain |
[SHOULD] |
Explicitly set, not too broad |
| Cookie name |
[CAN] |
No default name (session_id instead of connect.sid) |
REG — Registration Flow
OWASP ASVS: V2.1 (Password Security)
| Check |
Priority |
Description |
| Email validation |
[MUST] |
Server-side validation (not client-only) |
| Password policy |
[MUST] |
Min. 8 chars, no max limit under 64 (ASVS 2.1.1) |
| Password strength |
[SHOULD] |
Breached-password check or zxcvbn approach (ASVS 2.1.7) |
| Rate limiting |
[MUST] |
Registration endpoint rate-limited (ASVS 2.2.1) |
| Email uniqueness |
[MUST] |
Case-insensitive unique check (toLowerCase()) |
| Duplicate handling |
[SHOULD] |
No information disclosure ("email already registered") |
LOGIN — Login Flow
OWASP ASVS: V2.2 (General Authenticator Security)
| Check |
Priority |
Description |
| Generic error |
[MUST] |
Same message for wrong user/password (ASVS 2.2.1) |
| Brute-force protection |
[MUST] |
Rate limiting on login endpoint (ASVS 2.2.1) |
| Account lockout |
[SHOULD] |
Progressive delays or temporary lock (ASVS 2.2.3) |
| Timing attacks |
[MUST] |
Same response time for existing/non-existing user |
| Secure transport |
[MUST] |
Login only over HTTPS (ASVS 2.1.6) |
| Post-login redirect |
[SHOULD] |
Open redirect prevention on redirect URLs |
RESET — Password Reset
OWASP ASVS: V2.5 (Credential Recovery)
| Check |
Priority |
Description |
| Token entropy |
[MUST] |
Min. 128-bit cryptographically secure token (ASVS 2.5.6) |
| Token expiry |
[MUST] |
Max. 1 hour valid (ASVS 2.5.2) |
| One-time use |
[MUST] |
Token invalidated immediately after use |
| Secure delivery |
[MUST] |
Token only via email, not in URL response |
| Rate limiting |
[SHOULD] |
Reset request rate-limited |
| No user enumeration |
[MUST] |
Same response regardless of whether email exists (ASVS 2.5.1) |
AUTHZ — Authorization
OWASP ASVS: V4.1-V4.3 (Access Control)
| Check |
Priority |
Description |
| Route guards |
[MUST] |
All protected routes have auth check (ASVS 4.1.1) |
| Role-based access |
[SHOULD] |
Role check on admin/moderator routes |
| API protection |
[MUST] |
API endpoints authenticated (not just frontend routes) |
| IDOR prevention |
[MUST] |
Object access checked against user ownership (ASVS 4.2.1) |
| Default deny |
[MUST] |
New routes are protected by default |
| Privilege escalation |
[SHOULD] |
Role cannot be changed client-side |
STORE — Credential Storage
OWASP ASVS: V2.4 (Credential Storage), V6.4 (Secret Management)
| Check |
Priority |
Description |
| No plaintext |
[MUST] |
Passwords NEVER stored in plaintext (ASVS 2.4.1) |
| DB schema |
[MUST] |
Password field sufficiently long (VARCHAR(255) for bcrypt) |
| Env secrets |
[MUST] |
SESSION_SECRET, DB credentials in .env, not in code |
| .env in .gitignore |
[MUST] |
.env NOT in repository |
| Secret rotation |
[SHOULD] |
Documented process for secret rotation |
| Backup security |
[CAN] |
DB backups encrypted |
LOG — Auth Logging
OWASP ASVS: V7.1-V7.2 (Logging)
| Check |
Priority |
Description |
| Failed login attempts |
[SHOULD] |
Log failed logins with timestamp + IP |
| Session creation |
[SHOULD] |
Log new sessions (user ID, timestamp) |
| Privilege changes |
[SHOULD] |
Log role changes (ASVS 7.1.1) |
| Password changes |
[SHOULD] |
Log password changes (without the password!) |
| No sensitive data |
[MUST] |
NO passwords/tokens in logs (ASVS 7.1.2) |
| Log injection |
[SHOULD] |
User input in logs sanitized |
Check Priorities + Completeness Tracking
See _shared/audit-patterns.md (MUST/SHOULD/CAN markers, completeness counting, layer status standard).
Area with <100% MUST checks cannot be marked as done.
Severity Definitions
| Severity |
Criteria |
Examples |
| CRITICAL |
Direct auth bypass, data exfiltration possible |
Plaintext passwords, missing CSRF protection, session fixation, broken authentication |
| HIGH |
Significant weakness, exploitation realistic |
bcrypt rounds <10, missing rate limiting, insecure cookies (no httpOnly/secure) |
| MEDIUM |
Best-practice deviation, indirect risk |
Missing account lockout, no session rotation, weak password policy |
| LOW |
Nice-to-have, minimal risk |
Missing auth logging, no "remember me" security, UX improvements |
State Schema v2.1 (.auth-audit-state.json)
-> Full state schema (JSON example) + migration v1->v2.1: See state-schema.md
Rules
- Context protection: Max 2 areas OR 5 fixes per session. At limit: save state, recommend
/auth-audit continue.
- Write state immediately: Update
.auth-audit-state.json after every area and every fix.
- No auto-fix: Document findings, then ask user whether to fix.
- Severity rules: See severity definitions above.
- Finding prefix: Always
AUTH-NN, sequentially numbered.
- Fix templates: Load matching template from
fix-templates.md for findings.
- OWASP reference: Cite the ASVS section for every finding.
- No external auth: NextAuth, Lucia, Auth.js, Supabase Auth are OUT OF SCOPE. If detected: inform user, end skill.
- Security first: All defaults in fix templates must be secure. No insecure examples without warning.
Session Strategy
| Session |
Content |
Context Protection |
| 1 |
start -> Detection + 2 areas (CRITICAL first: HASH, SESS) |
Max 2 areas |
| 2 |
continue -> next 2 areas (CSRF, COOK) |
Max 2 areas |
| 3 |
continue -> next 2 areas (LOGIN, REG) |
Max 2 areas |
| 4 |
continue -> next 2 areas (RESET, AUTHZ) |
Max 2 areas |
| 5 |
continue -> last 2 areas (STORE, LOG) |
Max 2 areas |
| 6+ |
continue -> Fixes (max 5/session) |
Fix -> Test -> Next |
Smart Next Steps
After completing the auth audit, recommend relevant follow-up skills:
| Condition |
Recommendation |
Reason |
| DB schema findings present |
/db-audit start |
Check database schema and queries |
| SvelteKit project detected |
/sveltekit-audit start |
Check SvelteKit-specific patterns |
| No .audit-state.json present |
/audit start |
Check general website quality |
| No .project-audit-state.json present |
/project-audit start |
Check code/CI/CD quality |
| All areas done |
/lesson-learned session |
Extract learnings from auth audit |
Output after last area: "Next steps:" + 2-3 most relevant recommendations.
Additional Files
fix-templates.md — Quick-fix templates for common auth findingsstate-schema.md — State schema v2.1 + migration v1->v2.1
As of: 2026-03-20 (State schema v2.1 migration)
1---2name: auth-audit3description: Custom auth security audit (bcryptjs + sessions, no OAuth/external provider). Use when: "auth-audit", "auth check", "auth security", "login audit", "session audit", "password audit".4---56<!-- AI-QUICK-REF7## /auth-audit — Quick Reference8- **Modes:** start | continue | status | report | auto9- **Auto-Detection:** package.json (bcryptjs, argon2, jose), session handling, hooks.server.ts, middleware/guards10- **Focus:** Custom auth — bcryptjs + sessions. No NextAuth/Lucia/Auth.js/OAuth11- **State:** .auth-audit-state.json (v2.1)12- **Finding IDs:** AUTH-NN13- **Areas:** HASH, SESS, CSRF, COOK, REG, LOGIN, RESET, AUTHZ, STORE, LOG14- **Checkpoints:** [CHECKPOINT: decision] at framework detection, [CHECKPOINT: verify] after each area15- **OWASP Reference:** ASVS v4.0.3 — V2 (Authentication), V3 (Session Management)16- **Complementary to /audit** — this skill only checks auth-specific topics17-->1819# /auth-audit — Custom Auth Security Audit2021Security audit for custom auth implementations with bcryptjs/argon2 + session-based authentication. Checks against OWASP ASVS v4.0.3 (V2: Authentication, V3: Session Management).2223**Scope:** Custom auth — NO NextAuth, Lucia, Auth.js, or external OAuth provider. Focus on self-built registration, login, sessions, password reset.2425**Complementary to /audit:** This skill checks auth-specific security. The generic /audit checks code quality, performance, SEO, a11y, etc.2627## Modes2829Detect the mode from user input:3031- **start** -> Mode 1 (Scan project, detect auth stack)32- **continue** -> Mode 2 (Process next areas/fixes)33- **status** -> Mode 3 (Show progress)34- **report** -> Mode 4 (Structured Markdown report)35- **auto** -> Mode 5 (Fully autonomous run)3637---3839## Mode 1: `/auth-audit start` — Scan Project4041### Auto-Detection (in this order)42431. **package.json** -> Auth-relevant dependencies:44 - Hashing: `bcryptjs`, `bcrypt`, `argon2`, `@oslojs/crypto`45 - Tokens: `jose`, `jsonwebtoken`, `paseto`46 - Sessions: `express-session`, `iron-session`, `cookie`, `@sveltejs/kit` (built-in cookies)47 - Validation: `zod`, `valibot` (for auth input)48 - Rate limiting: `rate-limiter-flexible`, `express-rate-limit`492. **Framework detection:**50 - SvelteKit: `src/hooks.server.ts` with auth logic, `+page.server.ts` with form actions51 - Express/Fastify: Middleware files, route guards52 - Astro: `middleware.ts`, API routes under `src/pages/api/`533. **Search for auth files:**54 - `**/auth/**`, `**/login/**`, `**/register/**`, `**/session/**`55 - `**/middleware.*`, `**/guard.*`, `**/protect.*`56 - `**/*auth*.*`, `**/*session*.*`, `**/*password*.*`574. **Database schema:**58 - Drizzle: `schema.ts` / `schema/*.ts` -> Users table, Sessions table59 - Prisma: `schema.prisma` -> User/Session models60 - Raw SQL: `*.sql` migration files615. **Environment:**62 - `.env`, `.env.example` -> Auth-relevant secrets (SESSION_SECRET, JWT_SECRET, etc.)6364### Flow After Detection65661. Display result table: Framework, hashing lib, session type, DB schema, rate limiter672. [CHECKPOINT: decision] Confirm framework + auth approach683. Prioritize areas by severity order (max 2 per session)694. Check each checkpoint against the project (cite OWASP ASVS reference)705. Save findings to `.auth-audit-state.json`716. Display summary + prioritized list727. Session end: "Start next session with `/auth-audit continue`"7374---7576## Mode 2: `/auth-audit continue` — Resume77781. Read `.auth-audit-state.json`792. **Generate smart recommendation:**80 ```81 IF open CRITICAL findings > 0:82 -> "Recommendation: Fix {N} CRITICAL findings first ({IDs})"83 IF open HIGH findings > 3:84 -> "Recommendation: Fix HIGH findings, then continue"85 ELSE IF areas open:86 -> "Recommendation: Next areas ({area names})"87 ELSE:88 -> "Recommendation: Fix remaining findings"89 ```903. If areas open -> process next 2 areas914. If all areas done -> next 5 findings by priority925. **Load fix templates** (from `fix-templates.md`) where applicable936. Ask user: Follow recommendation? Choose different? Skip?947. Implement fixes -> verify -> update state9596---9798## Mode 3: `/auth-audit status` — Progress991001. Read `.auth-audit-state.json`1012. Display table: Done/Open/Total per area + severity1023. Show OWASP coverage (V2/V3 sections)1034. Next recommended action104105---106107## Mode 4: `/auth-audit report` — Markdown Report108109Generate a structured Markdown report.1101111. Read state file1122. Group all findings by area1133. Report with executive summary, findings per area, OWASP coverage, recommendations1144. **Insert trend analysis** (if history available):115 ```116 Trend (recent audits):117 CRITICAL: 3 -> 1 -> 0 (resolved)118 HIGH: 5 -> 3 -> 2 (declining)119 Total: 12 -> 8 -> 5120 Assessment: Project is steadily improving.121 ```1225. Save report as `AUTH-AUDIT-REPORT-{YYYY-MM-DD}.md` in project root1236. If previous reports exist: Diff section (new/resolved since last report)124125---126127## Mode 5: `/auth-audit auto` — Autonomous Run128129Fully autonomous auth audit without prompts.130131### Flow1321331. Auto-detection as in `start`1342. **All areas** processed (no 2-area limitation)1353. Document findings with fix templates from `fix-templates.md`1364. **Context management:** When context runs low:137 - Write state immediately138 - Create task in `.tasks.json` with handoff note139 - "New session with `/auth-audit continue`"1405. At end: Summary with prioritized fix list141142### Severity Order of Areas in Auto Mode143144CRITICAL areas first:145`HASH -> SESS -> CSRF -> COOK -> STORE -> LOGIN -> REG -> RESET -> AUTHZ -> LOG`146147---148149## Areas150151### HASH — Password Hashing152**OWASP ASVS:** V2.4 (Credential Storage)153154| Check | Priority | Description |155|-------|----------|-------------|156| Hashing algorithm | [MUST] | bcryptjs or argon2 (NOT md5, sha256, scrypt without config) |157| bcrypt rounds | [MUST] | Minimum 10 rounds, recommended 12 (ASVS 2.4.4) |158| Salt handling | [MUST] | bcryptjs.genSalt() or auto-salt via bcryptjs.hash(pw, rounds) |159| Timing-safe compare | [MUST] | Use bcryptjs.compare(), NEVER `===` on hashes |160| Pepper | [CAN] | HMAC pepper before hashing (server-side secret) |161162### SESS — Session Management163**OWASP ASVS:** V3.1-V3.7 (Session Management)164165| Check | Priority | Description |166|-------|----------|-------------|167| Session ID entropy | [MUST] | Min. 128-bit random value (crypto.randomUUID or @oslojs/crypto) |168| Session expiry | [MUST] | Absolute + idle timeout set (ASVS 3.3.1) |169| Session rotation | [MUST] | New session ID after login (ASVS 3.3.2 — session fixation prevention) |170| Session invalidation | [MUST] | Logout deletes server-side + cookie (ASVS 3.3.1) |171| Server-side storage | [MUST] | Sessions in DB, not client-cookie only (ASVS 3.2.1) |172| Concurrent sessions | [SHOULD] | Limit or display of active sessions |173174### CSRF — CSRF Protection175**OWASP ASVS:** V4.2.2 (Anti-CSRF)176177| Check | Priority | Description |178|-------|----------|-------------|179| SvelteKit origin check | [MUST] | Automatically active — NOT disabled (`csrf.checkOrigin: false`) |180| State-changing GET | [MUST] | No state changes via GET requests |181| Custom token | [SHOULD] | Double-submit cookie or synchronizer token for APIs |182| Fetch requests | [SHOULD] | Custom header (X-Requested-With) on AJAX calls |183184### COOK — Cookie Security185**OWASP ASVS:** V3.4 (Cookie-based Session Management)186187| Check | Priority | Description |188|-------|----------|-------------|189| httpOnly | [MUST] | Session cookie httpOnly: true (ASVS 3.4.2) |190| secure | [MUST] | secure: true in production (ASVS 3.4.1) |191| sameSite | [MUST] | sameSite: 'lax' or 'strict' (ASVS 3.4.3) |192| path | [SHOULD] | path: '/' (or more restrictive) |193| maxAge | [MUST] | Reasonable maxAge set (not unlimited) |194| domain | [SHOULD] | Explicitly set, not too broad |195| Cookie name | [CAN] | No default name (session_id instead of connect.sid) |196197### REG — Registration Flow198**OWASP ASVS:** V2.1 (Password Security)199200| Check | Priority | Description |201|-------|----------|-------------|202| Email validation | [MUST] | Server-side validation (not client-only) |203| Password policy | [MUST] | Min. 8 chars, no max limit under 64 (ASVS 2.1.1) |204| Password strength | [SHOULD] | Breached-password check or zxcvbn approach (ASVS 2.1.7) |205| Rate limiting | [MUST] | Registration endpoint rate-limited (ASVS 2.2.1) |206| Email uniqueness | [MUST] | Case-insensitive unique check (toLowerCase()) |207| Duplicate handling | [SHOULD] | No information disclosure ("email already registered") |208209### LOGIN — Login Flow210**OWASP ASVS:** V2.2 (General Authenticator Security)211212| Check | Priority | Description |213|-------|----------|-------------|214| Generic error | [MUST] | Same message for wrong user/password (ASVS 2.2.1) |215| Brute-force protection | [MUST] | Rate limiting on login endpoint (ASVS 2.2.1) |216| Account lockout | [SHOULD] | Progressive delays or temporary lock (ASVS 2.2.3) |217| Timing attacks | [MUST] | Same response time for existing/non-existing user |218| Secure transport | [MUST] | Login only over HTTPS (ASVS 2.1.6) |219| Post-login redirect | [SHOULD] | Open redirect prevention on redirect URLs |220221### RESET — Password Reset222**OWASP ASVS:** V2.5 (Credential Recovery)223224| Check | Priority | Description |225|-------|----------|-------------|226| Token entropy | [MUST] | Min. 128-bit cryptographically secure token (ASVS 2.5.6) |227| Token expiry | [MUST] | Max. 1 hour valid (ASVS 2.5.2) |228| One-time use | [MUST] | Token invalidated immediately after use |229| Secure delivery | [MUST] | Token only via email, not in URL response |230| Rate limiting | [SHOULD] | Reset request rate-limited |231| No user enumeration | [MUST] | Same response regardless of whether email exists (ASVS 2.5.1) |232233### AUTHZ — Authorization234**OWASP ASVS:** V4.1-V4.3 (Access Control)235236| Check | Priority | Description |237|-------|----------|-------------|238| Route guards | [MUST] | All protected routes have auth check (ASVS 4.1.1) |239| Role-based access | [SHOULD] | Role check on admin/moderator routes |240| API protection | [MUST] | API endpoints authenticated (not just frontend routes) |241| IDOR prevention | [MUST] | Object access checked against user ownership (ASVS 4.2.1) |242| Default deny | [MUST] | New routes are protected by default |243| Privilege escalation | [SHOULD] | Role cannot be changed client-side |244245### STORE — Credential Storage246**OWASP ASVS:** V2.4 (Credential Storage), V6.4 (Secret Management)247248| Check | Priority | Description |249|-------|----------|-------------|250| No plaintext | [MUST] | Passwords NEVER stored in plaintext (ASVS 2.4.1) |251| DB schema | [MUST] | Password field sufficiently long (VARCHAR(255) for bcrypt) |252| Env secrets | [MUST] | SESSION_SECRET, DB credentials in .env, not in code |253| .env in .gitignore | [MUST] | .env NOT in repository |254| Secret rotation | [SHOULD] | Documented process for secret rotation |255| Backup security | [CAN] | DB backups encrypted |256257### LOG — Auth Logging258**OWASP ASVS:** V7.1-V7.2 (Logging)259260| Check | Priority | Description |261|-------|----------|-------------|262| Failed login attempts | [SHOULD] | Log failed logins with timestamp + IP |263| Session creation | [SHOULD] | Log new sessions (user ID, timestamp) |264| Privilege changes | [SHOULD] | Log role changes (ASVS 7.1.1) |265| Password changes | [SHOULD] | Log password changes (without the password!) |266| No sensitive data | [MUST] | NO passwords/tokens in logs (ASVS 7.1.2) |267| Log injection | [SHOULD] | User input in logs sanitized |268269---270271## Check Priorities + Completeness Tracking272273> See `_shared/audit-patterns.md` (MUST/SHOULD/CAN markers, completeness counting, layer status standard).274Area with <100% MUST checks cannot be marked as `done`.275276---277278## Severity Definitions279280| Severity | Criteria | Examples |281|----------|----------|----------|282| **CRITICAL** | Direct auth bypass, data exfiltration possible | Plaintext passwords, missing CSRF protection, session fixation, broken authentication |283| **HIGH** | Significant weakness, exploitation realistic | bcrypt rounds <10, missing rate limiting, insecure cookies (no httpOnly/secure) |284| **MEDIUM** | Best-practice deviation, indirect risk | Missing account lockout, no session rotation, weak password policy |285| **LOW** | Nice-to-have, minimal risk | Missing auth logging, no "remember me" security, UX improvements |286287---288289## State Schema v2.1 (.auth-audit-state.json)290291-> Full state schema (JSON example) + migration v1->v2.1: See **state-schema.md**292293---294295## Rules296297- **Context protection:** Max 2 areas OR 5 fixes per session. At limit: save state, recommend `/auth-audit continue`.298- **Write state immediately:** Update `.auth-audit-state.json` after every area and every fix.299- **No auto-fix:** Document findings, then ask user whether to fix.300- **Severity rules:** See severity definitions above.301- **Finding prefix:** Always `AUTH-NN`, sequentially numbered.302- **Fix templates:** Load matching template from `fix-templates.md` for findings.303- **OWASP reference:** Cite the ASVS section for every finding.304- **No external auth:** NextAuth, Lucia, Auth.js, Supabase Auth are OUT OF SCOPE. If detected: inform user, end skill.305- **Security first:** All defaults in fix templates must be secure. No insecure examples without warning.306307---308309## Session Strategy310311| Session | Content | Context Protection |312|---------|---------|-------------------|313| 1 | start -> Detection + 2 areas (CRITICAL first: HASH, SESS) | Max 2 areas |314| 2 | continue -> next 2 areas (CSRF, COOK) | Max 2 areas |315| 3 | continue -> next 2 areas (LOGIN, REG) | Max 2 areas |316| 4 | continue -> next 2 areas (RESET, AUTHZ) | Max 2 areas |317| 5 | continue -> last 2 areas (STORE, LOG) | Max 2 areas |318| 6+ | continue -> Fixes (max 5/session) | Fix -> Test -> Next |319320---321322## Smart Next Steps323324After completing the auth audit, recommend relevant follow-up skills:325326| Condition | Recommendation | Reason |327|-----------|---------------|--------|328| DB schema findings present | `/db-audit start` | Check database schema and queries |329| SvelteKit project detected | `/sveltekit-audit start` | Check SvelteKit-specific patterns |330| No .audit-state.json present | `/audit start` | Check general website quality |331| No .project-audit-state.json present | `/project-audit start` | Check code/CI/CD quality |332| All areas done | `/lesson-learned session` | Extract learnings from auth audit |333334**Output after last area:** "Next steps:" + 2-3 most relevant recommendations.335336---337338## Additional Files339340- `fix-templates.md` — Quick-fix templates for common auth findings341- `state-schema.md` — State schema v2.1 + migration v1->v2.1342343As of: 2026-03-20 (State schema v2.1 migration)
claude-hangar