Security Audit

Step 1: Threat Modeling with STRIDE

Before scanning for specific vulnerabilities, understand what you're protecting and how it could be attacked. STRIDE gives you a systematic framework.

/agile-security-threat-model

Assets Identified:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  1. User data (PII, emails, addresses)
  2. Payment information (card tokens, billing)
  3. Session tokens (JWT, cookies)
  4. Admin panel access
  5. Order history and transaction logs

Attack Surfaces:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔓 Login endpoint     POST /api/auth/login
  🌐 Public API         GET/POST /api/products, /api/orders
  🛡️ Admin panel        GET /admin/* (role-gated)
  💳 Payment gateway    POST /api/checkout/pay
  📦 File uploads       POST /api/users/avatar

Apply STRIDE to each surface:

STRIDE — POST /api/auth/login
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  S — Spoofing:           Credential stuffing, brute force
  T — Tampering:          Manipulated login payloads
  R — Repudiation:        No audit log of failed attempts
  I — Info Disclosure:    Error messages reveal user existence
  D — Denial of Service:  No rate limiting on login
  E — Elevation:          SQL injection in username field

Risk Matrix — Pre-Launch
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Threat                  Likelihood  Impact    Risk
  SQL injection           High        Critical  🔴 S0
  Missing rate limiting   High        High      🟠 S1
  Session token in URL    Medium      High      🟠 S1
  Verbose error messages  Medium      Medium    🟡 S2
  Missing audit logs      Low         Medium    🔵 S3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 2: OWASP Top 10 Audit

Now scan the application against the OWASP Top 10 — the industry standard checklist for web application security.

/agile-security-audit

OWASP Top 10 Audit — e-commerce-app
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A01: Broken Access Control ........ ✅ PASS
A02: Cryptographic Failures ....... ✅ PASS
A03: Injection .................... ❌ FAIL
A04: Insecure Design .............. ✅ PASS
A05: Security Misconfiguration .... ⚠️ WARNING
A06: Vulnerable Components ........ ❌ FAIL (see scan)
A07: Auth Failures ................ ⚠️ WARNING
A08: Data Integrity Failures ...... ✅ PASS
A09: Logging Failures ............. ⚠️ WARNING
A10: SSRF ......................... ✅ PASS

Findings:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔴 S0 — SQL injection in search query
     Location: src/api/products/search.controller.ts:47
     Detail: User input concatenated directly into SQL query
     Fix: Use parameterized queries

  🟠 S1 — Session tokens exposed in URL parameters
     Location: src/middleware/auth.ts:23
     Detail: JWT passed as ?token= query param, logged by proxies
     Fix: Move token to Authorization header or HttpOnly cookie

  🟡 S2 — Missing rate limiting on login endpoint
     Location: src/api/auth/login.controller.ts
     Detail: No throttle — allows unlimited login attempts
     Fix: Add rate limiter (e.g., 5 attempts per minute)

  🔵 S3 — Verbose error messages in production
     Location: src/middleware/errorHandler.ts:12
     Detail: Stack traces and internal paths exposed in 500 errors
     Fix: Return generic error message in production mode

Step 3: Dependency CVE Scan

Third-party packages are a common attack vector. Scan all dependencies for known CVEs.

/agile-security-scan

Dependency CVE Scan — e-commerce-app
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Packages scanned: 134
Vulnerabilities found: 3

  🔴 Critical — jsonwebtoken@8.5.1
     CVE-2022-23529: Insecure key retrieval
     Fix: upgrade to jsonwebtoken@9.0.0+

  🟡 Medium — lodash@4.17.20
     CVE-2021-23337: Prototype pollution in zipObjectDeep
     Fix: upgrade to lodash@4.17.21

  🟡 Medium — lodash@4.17.20
     CVE-2020-28500: ReDoS in trim/trimEnd
     Fix: upgrade to lodash@4.17.21

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Action Required: 1 critical, 2 medium vulnerabilities

Step 4: Focused Code Review

Run a security-focused review on the authentication and authorization code — the highest-risk area of the application.

/agile-security-review

Security Code Review — Auth Module
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

File: src/api/auth/login.controller.ts
  ❌ Line 22: Input not validated before use
     → Add Zod/Joi schema validation for email and password

  ❌ Line 35: Password compared with == instead of ===
     → Use timing-safe comparison (crypto.timingSafeEqual)

File: src/config/app.config.ts
  ❌ Line 8: JWT_SECRET hardcoded as "supersecret123"
     → Move to environment variable, use strong random secret

File: src/middleware/cors.ts
  ⚠️ Line 5: CORS allows origin "*"
     → Restrict to known frontend domains

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Critical: 3  |  Warning: 1

Step 5: Triage All Findings

Consolidate every finding from the audit, scan, and review. Classify what blocks launch vs. what can wait.

Launch Blockers (must fix NOW):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔴 S0  SQL injection in product search
  🔴 CVE jsonwebtoken critical vulnerability
  🟠 S1  Session tokens exposed in URL
  🟠     Hardcoded JWT secret
  🟠     Missing input validation in auth

Post-Launch (track as tech debt):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🟡 S2  Missing rate limiting on login
  🟡     lodash prototype pollution (2 CVEs)
  🟡     CORS wildcard origin
  🔵 S3  Verbose error messages in production

Step 6: Fix Critical Findings with TDD

Write security tests first, then fix the code. This ensures the vulnerability cannot regress.

/agile-code-tdd

// test/security/sql-injection.test.ts
describe("SQL Injection Prevention", () => {
  it("rejects SQL in search query", async () => {
    const res = await request(app)
      .get("/api/products/search")
      .query({ q: "'; DROP TABLE products;--" });
    expect(res.status).toBe(400);
    expect(res.body.results).toBeUndefined();
  });

  it("sanitizes special characters in search", async () => {
    const res = await request(app)
      .get("/api/products/search")
      .query({ q: "shirt' OR '1'='1" });
    expect(res.status).toBe(200);
    expect(res.body.results).toHaveLength(0);
  });
});

// test/security/auth-tokens.test.ts
describe("Token Security", () => {
  it("rejects tokens passed as URL params", async () => {
    const res = await request(app)
      .get("/api/orders?token=valid.jwt.here");
    expect(res.status).toBe(401);
  });

  it("accepts tokens in Authorization header", async () => {
    const res = await request(app)
      .get("/api/orders")
      .set("Authorization", "Bearer valid.jwt.here");
    expect(res.status).toBe(200);
  });
});

Tests: 4 failing ❌ (expected — RED phase)

// src/api/products/search.controller.ts — FIXED
const results = await db.query(
  "SELECT * FROM products WHERE name ILIKE $1",
  [`%${sanitize(query)}%`]  // parameterized query
);

// src/middleware/auth.ts — FIXED
// Removed: const token = req.query.token
const token = req.headers.authorization?.replace("Bearer ", "");

// src/config/app.config.ts — FIXED
const JWT_SECRET = process.env.JWT_SECRET;
if (!JWT_SECRET) throw new Error("JWT_SECRET must be set");

Tests: 4 passing ✅ (GREEN phase)

Upgrade the vulnerable dependency:

npm install jsonwebtoken@9.0.2
npm install lodash@4.17.21

Step 7: Re-scan and Verify

Run the full pipeline and security scans again. Every blocker must be resolved.

/agile-code-ci

CI Pipeline — security-fixes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Build .................. ✅ PASS
Unit Tests ............. ✅ 156/156 passing
Integration Tests ...... ✅ 28/28 passing
Security Tests ......... ✅ 4/4 passing (new)
Lint ................... ✅ 0 issues
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Result: ✅ ALL CHECKS PASSED

/agile-security-scan

Dependency CVE Scan — re-scan
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Packages scanned: 134
Vulnerabilities found: 0

✅ CLEAN — no known vulnerabilities

/agile-security-audit

Re-Audit Results:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔴 S0  SQL injection ............ ✅ RESOLVED
  🔴 CVE jsonwebtoken ............. ✅ RESOLVED
  🟠 S1  Token in URL ............. ✅ RESOLVED
  🟠     Hardcoded secret ......... ✅ RESOLVED
  🟠     Missing input validation . ✅ RESOLVED

Launch Blockers Remaining: 0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ CLEAR FOR LAUNCH

Step 8: Track Remaining Items as Tech Debt

The 🟡 S2 and 🔵 S3 findings don't block launch, but they must not be forgotten. Create stories for the next sprint.

Sprint Backlog — Next Sprint:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  📋 SEC-001: Add rate limiting to login endpoint (🟡 S2)
     AC: Max 5 attempts per IP per minute, lockout after 10
  📋 SEC-002: Restrict CORS to known domains (🟡 S2)
     AC: Only frontend.example.com allowed
  📋 SEC-003: Sanitize error messages in production (🔵 S3)
     AC: No stack traces or file paths in error responses

Security Audit Flow

What You Practiced

• 🎯 /agile-security-threat-model — STRIDE analysis to identify assets and attack surfaces
• 🔍 /agile-security-audit — OWASP Top 10 scan with severity-classified findings
• 📦 /agile-security-scan — dependency CVE check to catch vulnerable packages
• 👁️ /agile-security-review — focused security code review on high-risk modules
• 🚦 Triaging findings into launch blockers (🔴/🟠) vs. tech debt (🟡/🔵)
• 🧪 /agile-code-tdd — writing security tests before fixing vulnerabilities
• 🔄 Re-scanning to verify all critical findings are resolved
• 📋 Tracking remaining items as stories for the next sprint