moai-ref-owasp-checklist
OWASP Top 10 security checklist, authentication patterns, input validation, and HTTP security headers reference. Agent-extending skill that amplifies backend-implementation and security-audit workflows with production-grade security patterns. NOT for: frontend UI, DevOps deployment, performance optimization, testing strategy.
68
Quality
83%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Securityby
Passed
No findings from the security scan
OWASP Security Checklist Reference
Target Agents
manager-develop- Applies checklist during backend API implementation (cycle_type=tddorcycle_type=dddcontext)/moai review --security- Primary security-audit invocation surface (replaces the retired/moai securitysubcommand per SPEC-SUBCOMMAND-RETIRE-001); equivalently available as a per-spawnAgent(general-purpose)security specialist perarchived-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 | SSRF (Server-Side Request Forgery) | Can URL input access internal resources? | URL whitelist, block internal IPs |
| A7 | Security Misconfiguration | Debug mode, default accounts exposed? | Separate prod config, inspect headers |
| A8 | Lack of Automated Threat Protection | Can APIs be called in abnormal sequences? | State machine validation, business rules |
| A9 | Improper Asset Management | Unused APIs, old versions exposed? | API inventory, version deprecation |
| 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 |
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. |
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
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
- Repository
- modu-ai/moai-adk
- Commit
05117b6
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.