security-audit · diff
git:20260131.424bd52 to git:20260211.29156b3
108 added, 5 removed. Audit A to A.
---
name: security-audit
- description: Perform a meticulous deep code audit covering Security, Logic, Completeness, and Quality. Manual analysis for critical systems.
+ description: Perform a meticulous deep code audit covering Security, Logic, Completeness, and Quality. Includes vibe-coding-specific guardrails for supply chain attacks, auth, rate limiting, and RLS.
---
# Security Audit Skill
- A comprehensive, manual deep code audit protocol for security-critical systems.
+ A comprehensive, manual deep code audit protocol for security-critical systems. Includes fast "Vibe Coding Guardrails" for the most common AI-assisted development pitfalls.
## When to Use
- Before major releases
- Security review requests
- Auditing authentication/payment flows
- When "audit" or "security" is mentioned
+ - After scaffolding a new project with AI (vibe coding sanity check)
+ - Before first deploy of any user-facing app
## Audit Phases
### Phase 0: Scope Definition
Define boundaries:
- **FULL_SCAN**: Entire codebase
- **FEATURE_SCAN**: Specific feature (`docs/features/[Name].md`)
- **DIFF_SCAN**: `git diff --staged` or `git diff HEAD~1`
### Phase 1: The Detective (Static Analysis)
```bash
- # 1. Dependency audit
- pnpm audit # or npm audit
+ # 1. Detect package manager & run dependency audit
+ # Auto-detect: check which lockfile exists
+ # pnpm-lock.yaml → pnpm audit
+ # package-lock.json → npm audit
+ # yarn.lock → yarn audit
+ # bun.lockb → bun pm audit (or bunx audit)
+ pnpm audit # ← swap for your package manager
# 2. Secret scanning (use jstar if available)
jstar detect
# 3. Manual grep patterns:
# Secrets
grep -rE "(api_key|secret|password|token)\s*[:=]\s*['\"\`][a-zA-Z0-9_\-\.]{10,}['\"\`]"
# RCE/Injection
grep -rE "(dangerouslySetInnerHTML|eval\(|exec\(|\.queryRaw)"
# Debugging
grep -rE "(console\.log|debugger|todo)"
```
+ ### Phase 1.5: Vibe Coding Guardrails (AI-Specific Checks)
+
+ > These are fast, proactive checks that catch the most common vibe-coding security mistakes.
+ > Run these **before** deep analysis. Each takes ~2 minutes.
+
+ #### 1.5.1 — Ghost/Phantom Package Detection (Supply Chain)
+ **Risk:** AI models hallucinate package names. Attackers register malware under those names.
+
+ > **Note:** `npm view` queries the npm registry directly and works regardless of your package manager (pnpm, yarn, bun, etc.). You don't need npm installed — it's just a registry lookup.
+
+ ```bash
+ # For each unfamiliar dependency in package.json:
+ # 1. Verify it exists on the real registry (works with ANY package manager)
+ npm view <package-name> version # Should return a version, not 404
+ # Alt for pnpm users: pnpm info <package-name>
+ # Alt for bun users: bunx npm-cli view <package-name>
+
+ # 2. Check download stats (low downloads = suspicious)
+ npm view <package-name> --json | grep -E "downloads|modified"
+
+ # 3. Look for typosquatting (e.g., "lodahs" instead of "lodash")
+ # Compare against known-good package names
+ ```
+ **Action:** Remove any package that doesn't exist on npm/PyPI or has suspiciously low downloads. Cross-reference with the official docs.
+
+ #### 1.5.2 — AI-Built Auth Detection
+ **Risk:** AI happily generates custom login systems that *look* like they work but have invisible holes (no CSRF, weak hashing, no session expiry, etc.).
+ ```bash
+ # Scan for custom auth patterns (red flags):
+ grep -rE "(bcrypt\.hash|jwt\.sign|createHash|crypto\.createCipher)" --include="*.ts" --include="*.tsx" --include="*.js"
+ grep -rE "(password.*=.*req\.(body|query)|session\[|cookie\[)" --include="*.ts" --include="*.tsx" --include="*.js"
+
+ # Check if a battle-tested auth provider is installed:
+ grep -E "(next-auth|@auth/|@clerk|@supabase/auth|auth0|lucia|better-auth)" package.json
+ ```
+ **Action:** If custom auth is found AND no established provider exists:
+ - Flag as **HIGH** severity
+ - Recommend migration to: **Clerk**, **NextAuth/Auth.js**, **Supabase Auth**, **Auth0**, **Lucia**, or **Better Auth**
+ - Custom auth is only acceptable if the team has dedicated security expertise
+
+ #### 1.5.3 — .gitignore Verification
+ **Risk:** Vibe coding moves fast. One missing `.gitignore` entry = secrets pushed to public GitHub. Bots scan for exposed keys 24/7.
+ ```bash
+ # 1. Check .gitignore exists
+ test -f .gitignore && echo "EXISTS" || echo "MISSING — CRITICAL"
+
+ # 2. Verify essential entries are present:
+ for pattern in ".env" ".env.local" ".env.*.local" "node_modules" "*.pem" "*.key" ".DS_Store"; do
+ grep -qF "$pattern" .gitignore || echo "MISSING from .gitignore: $pattern"
+ done
+
+ # 3. Check if .env is already tracked (damage already done):
+ git ls-files --cached | grep -E "\.env$|\.env\.local$|\.pem$|\.key$"
+ # If output exists → secrets are already in git history. Rotate ALL keys immediately.
+ ```
+ **Action:** If `.gitignore` is missing or incomplete → flag as **CRITICAL**. If `.env` is already tracked → **CRITICAL** + recommend `git filter-branch` or `BFG Repo-Cleaner` + immediate key rotation.
+
+ #### 1.5.4 — Rate Limiting Check
+ **Risk:** Any public API route without rate limiting = bots will abuse it (spam, brute force, API cost drain).
+ ```bash
+ # Check if rate limiting middleware is installed:
+ grep -E "(rate-limit|@upstash/ratelimit|express-rate-limit|limiter)" package.json
+
+ # Check if it's actually applied to API routes:
+ grep -rE "(rateLimit|rateLimiter|Ratelimit|slidingWindow)" --include="*.ts" --include="*.tsx" --include="*.js" src/app/api/ app/api/ pages/api/
+ ```
+ **Action:** If no rate limiter is found on public API routes:
+ - Flag as **HIGH** severity
+ - Recommend: `@upstash/ratelimit` (serverless), `express-rate-limit` (Express), or custom middleware
+ - Minimum: 100 requests/hour/IP for forms, 10 requests/minute for auth endpoints
+ - AI-powered endpoints (LLM calls) should have even stricter limits to prevent cost attacks
+
+ #### 1.5.5 — Row Level Security (RLS) Check
+ **Risk:** By default, databases let anyone see everyone's data. Forgetting RLS = instant data leak.
+ ```bash
+ # Check if Supabase is used (most common vibe-coding DB):
+ grep -E "(supabase|@supabase)" package.json
+
+ # If Supabase: verify RLS is mentioned in migration files or setup:
+ grep -rE "(enable_rls|row_level_security|CREATE POLICY|ALTER TABLE.*ENABLE ROW LEVEL SECURITY)" --include="*.sql" --include="*.ts"
+
+ # For Prisma: check for tenant/user scoping in queries:
+ grep -rE "where:.*userId|where:.*user_id|where:.*tenantId" --include="*.ts" --include="*.tsx"
+
+ # For raw SQL: check for user-scoped WHERE clauses:
+ grep -rE "(SELECT|UPDATE|DELETE).*FROM" --include="*.ts" --include="*.tsx" | grep -v "WHERE.*user"
+ ```
+ **Action:** If database is used but no RLS/user-scoping is found:
+ - Flag as **CRITICAL** severity
+ - For Supabase: Enable RLS on ALL tables, create policies for `SELECT`, `INSERT`, `UPDATE`, `DELETE`
+ - For Prisma/raw SQL: Ensure every query that touches user data includes a `userId`/`tenantId` filter
+ - Rule of thumb: **If a user can see another user's data, it's a data breach**
+
+ ---
+
### Phase 2: The Graph (Data Flow)
- Identify Entry Points (Routes, Actions, CLI)
- **Trace Input**: User input → Service → Database
- **Verify Validation**: Zod/Typebox at edge boundaries
### Phase 3: The Auditor (Spec vs Code)
- Read `docs/features/*.md` for scope
- **Gap Analysis**: Features in Docs but missing in Code
- **Orphan Analysis**: Code not in Docs (zombie code)
### Phase 4: The Judge (Logic Probing)
Pick highest-risk file and simulate:
- "What if I send `null`? Empty string? Negative ID?"
- "What if two requests hit this at once?" (race conditions)
- "Can I access this Service function directly?" (auth bypass)
### Phase 5: The Architect (Quality)
- **Performance**: `await` in loops → N+1 queries
- **Bloat**: Files > 200 lines? Functions > 50 lines?
- **Types**: Any use of `any` or `as unknown`?
- **Structure**: Feature-Sliced Design compliance?
### Phase 6: Report
Create `.jstar/audit_report.md`:
| Severity | Category | Location | Issue | Recommendation |
|----------|----------|----------|-------|----------------|
| CRITICAL | SECURITY | `api/auth` | ... | ... |
| HIGH | LOGIC | `service.ts:42` | ... | ... |
+ | HIGH | GUARDRAIL | `package.json` | No rate limiter installed | Add `@upstash/ratelimit` |
Severities: `CRITICAL`, `HIGH`, `WARNING`, `INFO`
- Categories: `SECURITY`, `LOGIC`, `COMPLETENESS`, `QUALITY`
+ Categories: `SECURITY`, `LOGIC`, `COMPLETENESS`, `QUALITY`, `GUARDRAIL`
### Phase 7: Remediation
For each CRITICAL/HIGH:
1. Implement fix
2. Run build/tests
3. Re-verify with grep/logic check
4. Stage changes