Generate comprehensive security audit checklist from architecture blueprint. Covers OWASP Top 10, data security, authentication, authorization, secrets management, compliance, and testing procedures.
Generates comprehensive security audit checklists from architecture blueprints, covering OWASP Top 10 and compliance standards.
npx claudepluginhub navraj007in/architecture-cowork-pluginThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Generate a comprehensive security audit checklist tailored to your architecture blueprint for pre-launch security validation.
Perfect for: Pre-launch security review, compliance validation, penetration testing prep, security team handoff
Use this skill when you need to:
Input: Architecture blueprint (especially Section 8: Security Architecture) Output: Security audit checklist (markdown + PDF)
security-audit-checklist.md:
# Security Audit Checklist
**Project**: Acme Ticketing Platform
**Generated**: 2026-02-07
**Architecture Version**: 1.0
---
## Overview
This checklist covers security controls for a **multi-tenant B2B SaaS** application built with:
- Frontend: Next.js 14 (Vercel)
- Backend: Next.js API Routes (Vercel)
- Database: PostgreSQL (Supabase)
- Auth: Clerk
- File Storage: Cloudflare R2
**Risk Level**: Medium (handles customer data, multi-tenant)
**Compliance**: None (SOC 2 planned for Year 2)
---
## 1. Authentication & Authorization
### 1.1 Authentication (Clerk)
- [ ] **Auth provider configured**: Clerk production keys set in environment
- [ ] **Password requirements enforced**: Minimum 8 characters, complexity rules
- [ ] **Email verification enabled**: Users must verify email before access
- [ ] **Password reset flow secure**: Reset tokens expire in 1 hour, single-use
- [ ] **Multi-factor authentication (MFA)**: Available for admin users
- [ ] **Session management**: JWT tokens expire in 15 minutes
- [ ] **Refresh tokens secure**: HttpOnly cookies, expire in 30 days
- [ ] **Account lockout**: After 5 failed login attempts, 15-minute lockout
- [ ] **OAuth providers**: Google OAuth configured and tested
- [ ] **Auth endpoints rate limited**: Max 5 login attempts per minute per IP
**Testing**:
- [ ] Attempt login with invalid credentials (should fail)
- [ ] Attempt login with expired token (should redirect to login)
- [ ] Verify MFA enforcement for admin accounts
- [ ] Test password reset flow end-to-end
- [ ] Verify session timeout after 15 minutes of inactivity
### 1.2 Authorization (RBAC)
- [ ] **Role-based access control (RBAC)**: Admin, Agent, Viewer roles defined
- [ ] **Permission matrix documented**: Each role's permissions listed
- [ ] **Admin-only routes protected**: Only admins can access workspace settings
- [ ] **Agent-only actions**: Only agents can be assigned tickets
- [ ] **Viewer restrictions**: Viewers can read but not modify tickets
- [ ] **Role escalation prevented**: Users cannot change their own role
- [ ] **Workspace isolation**: Users can only access their workspace data
**Testing**:
- [ ] Attempt to access admin route as Agent (should return 403)
- [ ] Attempt to modify ticket as Viewer (should return 403)
- [ ] Verify workspace isolation (user A cannot see user B's workspace)
- [ ] Test role downgrade (admin → agent should lose admin permissions)
---
## 2. Data Security
### 2.1 Multi-Tenant Data Isolation
- [ ] **Row-Level Security (RLS) enabled**: On all tables (tenants, users, tickets)
- [ ] **tenant_id on all tables**: Every row scoped by workspace
- [ ] **RLS policies tested**: Automated tests for each policy
- [ ] **Prisma middleware**: Automatically injects tenant_id filter
- [ ] **Cross-tenant leakage tested**: User A cannot query User B's data
- [ ] **Admin isolation**: Even admins cannot see other tenants without override
**Testing**:
- [ ] Run RLS test suite: `npm run test:rls`
- [ ] Manual test: Attempt cross-tenant query with modified SQL
- [ ] Verify Prisma middleware adds tenant_id to all queries
- [ ] Test with penetration testing tool (e.g., sqlmap)
### 2.2 Data Encryption
- [ ] **Data at rest encrypted**: Supabase encrypts all data (AES-256)
- [ ] **Data in transit encrypted**: HTTPS enforced (TLS 1.3)
- [ ] **Backup encryption**: Supabase backups are encrypted
- [ ] **Sensitive fields encrypted**: N/A (no PII beyond email)
- [ ] **Encryption keys rotated**: Managed by Supabase (automatic)
**Testing**:
- [ ] Verify HTTPS redirect (http://app.acme.com → https://app.acme.com)
- [ ] Check TLS version: `openssl s_client -connect app.acme.com:443`
- [ ] Verify no plaintext passwords in database (use Prisma to hash)
### 2.3 Secrets Management
- [ ] **No secrets in code**: All secrets in environment variables
- [ ] **Environment variables**: .env.local not committed to git
- [ ] **Secret rotation plan**: Rotate JWT_SECRET every 90 days
- [ ] **Vercel secrets**: All production secrets in Vercel dashboard
- [ ] **Database credentials**: Connection string in .env only
- [ ] **API keys encrypted**: All API keys stored as environment variables
- [ ] **Secret scanning**: GitHub secret scanning enabled
**Testing**:
- [ ] Scan repository for secrets: `git secrets --scan`
- [ ] Verify .gitignore excludes .env.local
- [ ] Check for hardcoded API keys: `grep -r "sk_live" .`
---
## 3. Application Security (OWASP Top 10)
### 3.1 Injection (A03:2021)
- [ ] **Parameterized queries**: Prisma ORM used (no raw SQL)
- [ ] **Input validation**: All user inputs validated (Zod schemas)
- [ ] **SQL injection prevented**: No string concatenation in queries
- [ ] **NoSQL injection**: N/A (PostgreSQL used)
- [ ] **Command injection**: No shell commands from user input
- [ ] **LDAP injection**: N/A (no LDAP integration)
**Testing**:
- [ ] Attempt SQL injection: `' OR 1=1 --` in email field
- [ ] Attempt command injection: `; rm -rf /` in file upload
- [ ] Use SQLMap to scan for SQL injection vulnerabilities
### 3.2 Broken Access Control (A01:2021)
- [ ] **Direct object reference**: All queries scoped by tenant_id
- [ ] **Forced browsing**: Cannot access /admin without admin role
- [ ] **Missing function level access control**: API checks roles
- [ ] **Insecure direct object references**: Ticket IDs not guessable (CUID)
- [ ] **CORS configured**: Only allow app.acme.com origin
**Testing**:
- [ ] Attempt to access /api/tickets/:id from different tenant
- [ ] Attempt to access /admin as non-admin user
- [ ] Verify CORS headers: `curl -H "Origin: https://evil.com" https://api.acme.com`
### 3.3 Cryptographic Failures (A02:2021)
- [ ] **HTTPS enforced**: All traffic over HTTPS (no HTTP)
- [ ] **TLS 1.3 enabled**: Modern TLS version
- [ ] **Strong cipher suites**: Only secure ciphers allowed
- [ ] **HSTS enabled**: Strict-Transport-Security header set
- [ ] **Password hashing**: Bcrypt with 10+ rounds (handled by Clerk)
- [ ] **Session tokens**: JWT with HS256 algorithm
**Testing**:
- [ ] Verify HSTS header: `curl -I https://app.acme.com`
- [ ] Check TLS version: `nmap --script ssl-enum-ciphers -p 443 app.acme.com`
- [ ] Verify no weak ciphers (3DES, RC4, MD5)
### 3.4 Cross-Site Scripting (XSS)
- [ ] **Input sanitization**: All user input escaped (React auto-escapes)
- [ ] **Content-Security-Policy (CSP)**: CSP header configured
- [ ] **X-XSS-Protection**: Header enabled
- [ ] **Dangerous HTML disabled**: No dangerouslySetInnerHTML used
- [ ] **User-generated content sanitized**: DOMPurify for rich text
**Testing**:
- [ ] Attempt XSS: `<script>alert('XSS')</script>` in ticket title
- [ ] Verify CSP header blocks inline scripts
- [ ] Test with XSS payloads: `<img src=x onerror=alert(1)>`
### 3.5 Cross-Site Request Forgery (CSRF)
- [ ] **CSRF tokens**: Next.js API routes have CSRF protection
- [ ] **SameSite cookies**: Session cookies use SameSite=Strict
- [ ] **Double-submit cookies**: Additional CSRF protection for forms
- [ ] **State-changing requests**: Only POST/PUT/DELETE (not GET)
**Testing**:
- [ ] Attempt CSRF attack from external site
- [ ] Verify SameSite cookie attribute: `document.cookie` in console
### 3.6 Security Misconfiguration (A05:2021)
- [ ] **Default credentials changed**: No default admin/admin accounts
- [ ] **Debug mode disabled**: NODE_ENV=production
- [ ] **Error messages sanitized**: No stack traces in production
- [ ] **Unnecessary services disabled**: No unused API endpoints
- [ ] **Security headers**: X-Frame-Options, X-Content-Type-Options
- [ ] **Directory listing disabled**: Vercel disables by default
**Testing**:
- [ ] Verify production environment: Check NODE_ENV
- [ ] Trigger error and verify no stack trace shown
- [ ] Check security headers: `curl -I https://app.acme.com`
### 3.7 Vulnerable Components (A06:2021)
- [ ] **Dependency scanning**: Dependabot or Snyk enabled
- [ ] **Package vulnerabilities**: `npm audit` shows no high/critical
- [ ] **Outdated packages**: All packages within 1 major version
- [ ] **License compliance**: No GPL/AGPL packages (if commercial)
**Testing**:
- [ ] Run: `npm audit --audit-level=high`
- [ ] Run: `npm outdated`
- [ ] Check for known vulnerabilities in dependencies
### 3.8 Logging & Monitoring (A09:2021)
- [ ] **Authentication events logged**: Login, logout, failed attempts
- [ ] **Authorization failures logged**: 403 errors logged to Sentry
- [ ] **Input validation failures logged**: Malformed requests logged
- [ ] **Centralized logging**: All logs sent to Sentry or Datadog
- [ ] **Log retention**: Logs retained for 90 days minimum
- [ ] **Alerting configured**: Alerts on repeated failed logins
**Testing**:
- [ ] Verify failed login is logged: Check Sentry dashboard
- [ ] Trigger 403 error and verify logged
- [ ] Check log retention policy in logging provider
### 3.9 Server-Side Request Forgery (SSRF)
- [ ] **URL validation**: All external URLs validated before fetching
- [ ] **Whitelist approach**: Only allow known domains (e.g., Slack API)
- [ ] **No user-controlled URLs**: Users cannot specify fetch URLs
- [ ] **Network segmentation**: API cannot access internal networks
**Testing**:
- [ ] Attempt to fetch internal URL: `http://169.254.169.254/` (AWS metadata)
- [ ] Verify URL whitelist blocks unknown domains
### 3.10 Insecure Design (A04:2021)
- [ ] **Threat modeling**: Well-Architected Review completed
- [ ] **Security requirements**: Defined in blueprint (Section 8)
- [ ] **Rate limiting**: All public endpoints rate limited
- [ ] **Input validation**: All inputs validated with Zod schemas
- [ ] **Secure defaults**: Fail-secure (deny by default)
**Testing**:
- [ ] Review Well-Architected Review section of blueprint
- [ ] Verify rate limiting: Exceed limit and get 429 response
---
## 4. API Security
### 4.1 API Authentication
- [ ] **Bearer tokens**: All protected endpoints require JWT
- [ ] **Token validation**: Verify JWT signature and expiration
- [ ] **Token in Authorization header**: Not in URL or body
- [ ] **API key rotation**: Clerk keys rotated every 90 days
**Testing**:
- [ ] Call API without token (should return 401)
- [ ] Call API with expired token (should return 401)
- [ ] Verify token not in URL: Check access logs
### 4.2 Rate Limiting
- [ ] **Global rate limit**: 60 requests/minute per IP
- [ ] **Auth endpoints**: 5 requests/minute per IP
- [ ] **Rate limit headers**: X-RateLimit-Limit, X-RateLimit-Remaining
- [ ] **Rate limit bypass prevented**: Cannot bypass with IP spoofing
- [ ] **DDoS protection**: Vercel DDoS mitigation enabled
**Testing**:
- [ ] Exceed rate limit and verify 429 response
- [ ] Check rate limit headers in response
- [ ] Attempt IP spoofing to bypass rate limit
### 4.3 Input Validation
- [ ] **Request validation**: All requests validated with Zod
- [ ] **Type checking**: TypeScript types enforced
- [ ] **String length limits**: Max lengths enforced (title: 200 chars)
- [ ] **Numeric ranges**: Valid ranges (priority: 1-4)
- [ ] **Enum validation**: Status must be OPEN|IN_PROGRESS|RESOLVED|CLOSED
**Testing**:
- [ ] Send invalid JSON (malformed)
- [ ] Send extra-long strings (>1MB)
- [ ] Send invalid enum values
### 4.4 Output Encoding
- [ ] **JSON responses**: Properly encoded (application/json)
- [ ] **No sensitive data**: Passwords, tokens excluded from responses
- [ ] **Error messages**: Generic (not revealing internal details)
- [ ] **Stack traces**: Never returned in production
**Testing**:
- [ ] Verify passwords not in user object response
- [ ] Trigger error and verify generic message
- [ ] Check Content-Type header: application/json
---
## 5. File Upload Security
### 5.1 Upload Validation
- [ ] **File type validation**: Only allow images (PNG, JPG, GIF, WebP)
- [ ] **File size limit**: Max 10MB per file
- [ ] **Virus scanning**: Cloudflare R2 scans uploads
- [ ] **Content-Type validation**: Check MIME type, not just extension
- [ ] **File name sanitization**: Remove special characters
**Testing**:
- [ ] Upload executable (.exe, .sh) - should reject
- [ ] Upload >10MB file - should reject
- [ ] Upload file with malicious name: `../../etc/passwd.jpg`
### 5.2 Storage Security
- [ ] **Presigned URLs**: R2 presigned URLs for uploads (expire in 1 hour)
- [ ] **Private buckets**: R2 bucket not publicly listable
- [ ] **Access control**: Only authenticated users can upload
- [ ] **CDN caching**: Uploaded files served via CDN with cache headers
- [ ] **URL randomization**: File URLs not guessable (UUID)
**Testing**:
- [ ] Attempt to list bucket contents (should fail)
- [ ] Attempt to access file without presigned URL
- [ ] Verify presigned URL expires after 1 hour
---
## 6. Compliance & Privacy
### 6.1 Data Privacy (GDPR)
- [ ] **Privacy policy**: Published and linked in footer
- [ ] **Cookie consent**: Banner shown for EU users
- [ ] **Data deletion**: Users can delete their account and data
- [ ] **Data export**: Users can export their data (tickets, comments)
- [ ] **Data retention**: Soft deletes, 90-day grace period
- [ ] **Third-party processors**: Documented (Clerk, Supabase, Vercel)
**Testing**:
- [ ] Verify privacy policy link works
- [ ] Test account deletion flow
- [ ] Test data export (download JSON)
### 6.2 HIPAA (If Healthcare)
- [ ] **N/A**: No healthcare data in this application
### 6.3 SOC 2 (If Enterprise SaaS)
- [ ] **Planned for Year 2**: Not currently required
---
## 7. Infrastructure Security
### 7.1 Network Security
- [ ] **Firewall rules**: Managed by Vercel and Supabase
- [ ] **Private networks**: Database not publicly accessible
- [ ] **VPN access**: N/A (managed platforms)
- [ ] **IP whitelisting**: Admin panel IP-restricted (optional)
**Testing**:
- [ ] Attempt to connect to database from public IP (should fail)
- [ ] Verify Supabase connection pooler security
### 7.2 Database Security
- [ ] **Database backups**: Supabase backs up every 5 minutes
- [ ] **Backup encryption**: Encrypted at rest
- [ ] **Point-in-time recovery**: Available (last 7 days)
- [ ] **Connection pooling**: Supabase Pooler enabled
- [ ] **Database credentials**: Rotated every 90 days
- [ ] **Database firewall**: Only allow connections from Vercel IPs
**Testing**:
- [ ] Verify backups exist in Supabase dashboard
- [ ] Test point-in-time recovery (staging only)
- [ ] Attempt to connect from unauthorized IP
### 7.3 Container/Serverless Security
- [ ] **Vercel runtime**: Secure by default (sandboxed)
- [ ] **Environment isolation**: Staging and production separated
- [ ] **No root access**: Serverless functions run as non-root
- [ ] **Resource limits**: Memory and CPU limits enforced
**Testing**:
- [ ] Verify staging and production use different databases
- [ ] Check Vercel deployment logs for errors
---
## 8. Monitoring & Incident Response
### 8.1 Security Monitoring
- [ ] **Sentry configured**: Error tracking enabled
- [ ] **Failed login tracking**: Alerts on >10 failed logins/minute
- [ ] **Anomaly detection**: Unusual traffic patterns alert
- [ ] **Log analysis**: Automated log analysis for threats
- [ ] **Uptime monitoring**: Vercel Analytics enabled
**Testing**:
- [ ] Trigger 10 failed logins and verify alert
- [ ] Verify Sentry receives errors
- [ ] Check uptime monitoring dashboard
### 8.2 Incident Response Plan
- [ ] **Incident response team**: CTO + Lead Dev
- [ ] **Escalation procedure**: Documented in runbook
- [ ] **Communication plan**: Email + Slack for incidents
- [ ] **Breach notification**: 72-hour GDPR timeline
- [ ] **Post-mortem process**: RCA within 48 hours
**Testing**:
- [ ] Review incident response runbook
- [ ] Simulate incident and test escalation
---
## 9. Security Testing
### 9.1 Automated Testing
- [ ] **Unit tests for auth**: 95% coverage on auth flows
- [ ] **Integration tests**: API endpoint tests with auth
- [ ] **E2E tests**: Playwright tests for critical flows
- [ ] **Security linting**: ESLint security rules enabled
- [ ] **Dependency scanning**: Automated (Dependabot)
**Testing**:
- [ ] Run: `npm run test` (95% coverage achieved)
- [ ] Run: `npm run test:e2e`
- [ ] Check ESLint security plugin enabled
### 9.2 Manual Testing
- [ ] **Penetration testing**: Scheduled for before launch
- [ ] **Code review**: Security-focused code review
- [ ] **Threat modeling**: Completed in blueprint
- [ ] **Red team exercise**: N/A (planned for Year 2)
**Testing**:
- [ ] Schedule penetration test with vendor (Bishop Fox, etc.)
- [ ] Conduct internal security code review
---
## 10. Third-Party Integrations
### 10.1 Integration Security
- [ ] **Slack integration**: Webhook URL in environment variable
- [ ] **Stripe integration**: Webhook signature verification
- [ ] **OAuth scopes**: Minimum required scopes only
- [ ] **API keys rotated**: Every 90 days
- [ ] **Webhook validation**: Verify signatures on all webhooks
**Testing**:
- [ ] Verify Stripe webhook signature validation
- [ ] Test Slack webhook with invalid signature
- [ ] Review OAuth scope requests (minimum principle)
---
## Pre-Launch Checklist
**Critical (Must Fix Before Launch)**:
- [ ] All RLS policies tested and passing
- [ ] Penetration test completed with no critical findings
- [ ] Rate limiting enabled on all public endpoints
- [ ] HTTPS enforced everywhere
- [ ] Secrets not in code repository
- [ ] Database backups configured and tested
- [ ] Error tracking (Sentry) configured
- [ ] Security headers configured
- [ ] Input validation on all endpoints
- [ ] Authentication and authorization tested
**High Priority (Should Fix Before Launch)**:
- [ ] XSS prevention tested
- [ ] CSRF protection enabled
- [ ] File upload validation working
- [ ] Dependency vulnerabilities resolved
- [ ] Logging and monitoring configured
- [ ] Privacy policy published
- [ ] Data export functionality working
**Medium Priority (Fix Within 30 Days)**:
- [ ] MFA available for admin users
- [ ] Security documentation complete
- [ ] Incident response plan documented
- [ ] Cookie consent for EU users
- [ ] Account lockout after failed attempts
---
## Sign-Off
**Security Review Completed By**: _______________________
**Date**: _______________________
**Security Posture**: ☐ Ready for Launch ☐ Needs Fixes ☐ Major Issues
**Notes**:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
**Next Security Review Date**: _______________________
When invoked, generate:
🔒 Generating security audit checklist...
✅ Analyzed security architecture (Section 8)
✅ Detected product type: Multi-tenant B2B SaaS
✅ Detected authentication: Clerk (JWT)
✅ Detected database: PostgreSQL with RLS
✅ Detected compliance requirements: None (SOC 2 planned)
📋 Generating checklist sections...
✅ 1. Authentication & Authorization (25 checks)
✅ 2. Data Security (18 checks)
✅ 3. Application Security - OWASP Top 10 (47 checks)
✅ 4. API Security (22 checks)
✅ 5. File Upload Security (11 checks)
✅ 6. Compliance & Privacy (8 checks)
✅ 7. Infrastructure Security (12 checks)
✅ 8. Monitoring & Incident Response (9 checks)
✅ 9. Security Testing (8 checks)
✅ 10. Third-Party Integrations (5 checks)
📄 Created security-audit-checklist.md (287 checks total)
📄 Created security-audit-summary.pdf (executive summary)
🎯 Checklist tailored to your architecture:
- Multi-tenant data isolation (RLS)
- Clerk authentication
- Cloudflare R2 file uploads
- Stripe integration security
- Slack webhook validation
🚨 Critical security items (must fix before launch):
1. Enable and test Row-Level Security policies
2. Configure rate limiting on authentication endpoints
3. Schedule penetration testing (budget: $5K-15K)
4. Verify HTTPS enforced everywhere
5. Test webhook signature validation (Stripe, Slack)
📋 Pre-launch checklist: 35 critical items
Next steps:
1. Review security-audit-checklist.md with team
2. Assign checklist items to developers
3. Schedule penetration testing
4. Complete all critical items before launch
5. Sign off on security review
Optional parameters:
Examples:
# Basic security audit
/architect:security-audit
# HIPAA compliance
/architect:security-audit --compliance=hipaa
# High-risk application
/architect:security-audit --risk=high
# Export to PDF
/architect:security-audit --format=pdf
A comprehensive security audit checklist should:
/architect:security-audit
# Output: security-audit-checklist.md with 287 checks
/architect:security-audit --compliance=hipaa
# Additional checks: PHI encryption, BAA vendors, audit logs
/architect:security-audit --format=pdf
# Output: security-audit-checklist.pdf for printing
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.