OWASP Security Checklist Reference

Target Agents

• manager-develop - Applies checklist during backend API implementation (cycle_type=tdd or cycle_type=ddd context)
• /moai review with a security focus - Primary security-audit invocation surface; equivalently available as a per-spawn Agent(general-purpose) security specialist per archived-agent-rejection.md §C

OWASP API Security Top 10

| Rank | Vulnerability | Check | Defense | |------|-------------|-------|---------| | A1 | BOLA (Broken Object Level Authorization) | Can user A access user B's resources? | Verify object ownership at every endpoint | | A2 | Broken Authentication | Weak passwords, unlimited login attempts? | bcrypt (cost 12+), rate limit, MFA | | A3 | Broken Object Property Level Authorization | Are hidden fields exposed in responses? | Response DTOs, field-level filtering | | A4 | Unrestricted Resource Consumption | Can mass requests crash the server? | Rate limiting, enforce pagination limits | | A5 | Broken Function Level Authorization | Can regular users call admin APIs? | RBAC middleware, permission checks | | A6 | Unrestricted Access to Sensitive Business Flows | Can a sensitive flow be automated or abused in bulk? | Flow-level rate limits, anomaly detection, challenge on abuse signals | | A7 | SSRF (Server-Side Request Forgery) | Can URL input reach internal or metadata endpoints? | Egress allowlist, block internal/metadata ranges, validate fetch targets | | A8 | Security Misconfiguration | Debug mode, verbose errors, or default accounts exposed? | Production-hardened config, security headers, inspect deployed config | | A9 | Improper Inventory Management | Undocumented, shadow, or old-version endpoints reachable? | Maintain an API inventory; deprecate and decommission old versions | | A10 | Unsafe API Consumption | Are external API responses trusted blindly? | Validate external responses, set timeouts |

Authentication Checklist

Password Policy

• Minimum 8 characters, show strength meter (not strict rules)
• bcrypt (cost factor 12+) or Argon2id
• Temporary lock after 5 failed attempts (15 min) or CAPTCHA
• Prevent reuse of last 5 passwords

JWT Configuration

| Setting | Recommended Value | |---------|------------------| | Access Token Expiry | 15-30 minutes | | Refresh Token Expiry | 7-14 days | | Algorithm | RS256 (asymmetric) or HS256 | | Storage | httpOnly + secure + sameSite cookie | | Payload | Minimal: userId, role only (no PII) | | Renewal | Silent refresh or token rotation |

Session Security

• Regenerate session ID after login
• Invalidate session on logout (server-side)
• Set session timeout (30 min idle)
• Bind session to IP/User-Agent (optional, strict)

HTTP Security Headers

| Header | Value | Purpose | |--------|-------|---------| | Strict-Transport-Security | max-age=31536000; includeSubDomains | Force HTTPS | | X-Content-Type-Options | nosniff | Prevent MIME sniffing | | X-Frame-Options | DENY or SAMEORIGIN | Prevent clickjacking | | Content-Security-Policy | default-src 'self' | Prevent XSS | | Referrer-Policy | strict-origin-when-cross-origin | Limit referrer | | Permissions-Policy | camera=(), microphone=() | Restrict browser features |

Input Validation Checklist

| Type | Method | Tool | |------|--------|------| | Schema validation | Type + structure check | Zod, Joi, pydantic, Go validator | | Length limits | Min/max constraints | Schema definitions | | SQL Injection | Parameterized queries | ORM (Prisma, GORM, SQLAlchemy) | | XSS Prevention | HTML escaping | DOMPurify (client), server escape | | Path Traversal | Path normalization | filepath.Clean + whitelist | | File Upload | Type + size validation | MIME type + magic number check | | CORS | Origin whitelist | Never origin: '*' with credentials |

Sensitive Data Handling

| Data Type | Storage | Transmission | Logging | |----------|---------|-------------|---------| | Passwords | bcrypt hash only | HTTPS only | NEVER | | API Keys | Environment variables | Header (Authorization) | Masked (first 4 chars) | | PII | Encrypted (AES-256) | HTTPS only | Masked | | Credit Cards | Tokenized (payment provider) | Provider SDK | NEVER | | Sessions | httpOnly cookie | HTTPS only | NEVER |

Security Review Severity Levels

| Level | Label | Action | Example | |-------|-------|--------|---------| | P0 | CRITICAL | Block release | SQL injection, auth bypass | | P1 | HIGH | Fix before merge | Missing authorization check | | P2 | MEDIUM | Fix within sprint | Weak password policy | | P3 | LOW | Track in backlog | Missing security header |

Trust Boundary Verification Principles

| Principle | Applies To | Defense | |-----------|------------|---------| | Cached/client-supplied session state is not proof of current identity | Any framework caching or locally decoding a session/JWT value | Re-verify identity against the server-side source of truth (session store, token introspection, identity provider) before every authorization decision | | Edge/gateway/middleware auth checks are a UX convenience, not a security boundary | Reverse proxies, framework middleware, API gateways, serverless edge functions | Every mutation-handling endpoint independently re-checks authentication AND resource-ownership authorization | | Scheduled/cron-triggered HTTP endpoints are still public URLs | Any scheduler that invokes an HTTP endpoint (cron jobs, scheduled serverless functions, container-orchestrator scheduled jobs) | Require a shared-secret bearer check (constant-time compare) on every scheduled-endpoint invocation | | Production builds must not expose source maps or equivalent debug artifacts | Any bundler/build tool | Disable production source maps, verbose stack traces, and build manifests in production configuration | | Webhook receivers must verify a signature/HMAC header before trusting the payload | Any webhook provider | Verify signature/HMAC against a shared secret before treating the payload as legitimate business data |

<!-- moai:evolvable-start id="rationalizations" -->

Common Rationalizations

| Rationalization | Reality | |---|---| | "This is an internal application, OWASP does not apply" | Internal applications are reachable from compromised internal services. OWASP applies to all web applications. | | "The framework handles XSS protection" | Frameworks protect default rendering paths. Dynamic HTML insertion, innerHTML, and template literals bypass the protection. | | "We do not store sensitive data, so encryption is unnecessary" | Session tokens, API keys, and PII are sensitive data. If the application has users, it has sensitive data. | | "Security headers are just defense-in-depth, not critical" | Each security header blocks a specific attack class. Missing CSP enables XSS even when output is escaped. | | "I will do a security review before release" | Late security reviews find issues that are expensive to fix. Secure coding practices prevent them from the start. |

<!-- moai:evolvable-end -->

<!-- moai:evolvable-start id="red-flags" -->

Red Flags

• User input rendered in HTML without escaping or sanitization
• SQL query built with string concatenation instead of parameterized queries
• Authentication token stored in localStorage instead of httpOnly cookie
• Missing Content-Security-Policy header on response
• Secrets (API keys, passwords) found in source code or configuration files committed to git

<!-- moai:evolvable-end -->

<!-- moai:evolvable-start id="verification" -->

Verification

• ] OWASP Top 10 checklist reviewed for the change (show which items were evaluated)
• ] User input sanitized before rendering in HTML output
• ] All database queries use parameterized statements
• ] Security headers present (CSP, X-Frame-Options, X-Content-Type-Options)
• ] No secrets found in source code (show grep results for common secret patterns)
• ] Authentication tokens use httpOnly, Secure, SameSite cookie attributes

<!-- moai:evolvable-end -->