DKDDokodoA place for everything
Back to docs hub·docs/ops/32-production-security-checklist.md
Reference document

32 Production Security Checklist

Last updated Mar 23, 2026

32 Production Security Checklist

Purpose

Comprehensive security checklist derived from December 2024 security audit. This document tracks security requirements for production deployment and paid subscription launch.

Security Audit Summary (Dec 2024)

Overall Assessment: B+ (Very Good)

The app has excellent authentication, authorization, and input validation. Main gaps are operational (CSP, session management, audit logs) rather than fundamental flaws.

Critical (Must Fix Before Any Production Deploy)

✅ 1. HTTPS Enforcement

  • Status: Ready for production
  • Requirements:
    • Set COOKIE_SECURE=true in production environment
    • Set NODE_ENV=production on hosting platform
    • Verify TLS certificate is active
  • Testing: Confirm auth cookies have Secure flag in browser DevTools
  • Render Config: Platform provides auto-SSL, just set env vars

✅ 2. Strong Secret Generation

  • Status: Template updated with instructions
  • Requirements:
    • Generate JWT_ACCESS_SECRET with 48+ bytes entropy
    • Generate JWT_REFRESH_SECRET with 48+ bytes entropy (different from access)
    • Use: openssl rand -base64 48
  • Testing: Secrets should be different and 64+ characters
  • Rotation: Every 90 days or on suspected compromise

✅ 3. Database Connection Security

  • Status: Documentation updated
  • Requirements:
    • Add ?sslmode=require to production DATABASE_URL
    • Verify SSL/TLS enforcement in provider settings
  • Testing: Check Postgres logs for encrypted connections
  • Note: Most managed Postgres (Render, Supabase, etc.) enforce SSL by default

✅ 4. Environment Variable Validation

  • Status: ✅ Complete
  • Requirements:
    • Validate all required env vars on startup
    • Fail fast with clear error messages
    • Check format/type (URLs, ports, etc.)
  • Testing: Start app with missing vars, should exit with helpful error
  • Implementation: EnvValidationService in backend/src/common/config/
  • Completed: Dec 30, 2024

High Priority (Before Public Beta)

✅ 5. Content Security Policy (CSP)

  • Status: ✅ Complete
  • Requirements:
    • Configure CSP headers for frontend pages
    • Allow Next.js runtime and framework scripts
    • Restrict inline scripts and unsafe-eval
    • Block unauthorized external resources
  • Testing: Run Chrome Lighthouse security audit, check browser console for CSP violations
  • Implementation:
    • Frontend: CSP headers configured in next.config.ts
    • Backend: Additional security headers via Helmet.js in app.setup.ts
  • Features:
    • Environment-aware CSP (stricter in production)
    • Whitelists API origin for fetch requests
    • Allows HTTPS images for S3 uploads
    • Blocks framing (X-Frame-Options: DENY)
    • Referrer policy: strict-origin-when-cross-origin
    • Permissions policy: blocks camera, microphone, geolocation
  • Security Headers:
    • Content-Security-Policy - Restricts resource loading
    • X-Frame-Options: DENY - Prevents clickjacking
    • X-Content-Type-Options: nosniff - Prevents MIME-sniffing
    • Referrer-Policy - Controls referrer information
    • Permissions-Policy - Disables unnecessary browser features
    • Strict-Transport-Security (backend) - Enforces HTTPS
  • CSP Directives:
    • default-src 'self' - Only allow same-origin resources
    • script-src - Allows Next.js inline scripts (required for framework)
    • style-src - Allows inline styles (required for CSS-in-JS)
    • img-src - Allows data:, blob:, and https: for uploads
    • connect-src - Whitelists API backend origin
    • frame-ancestors 'none' - Prevents all embedding
    • upgrade-insecure-requests - Auto-upgrades HTTP to HTTPS (production only)
  • Note: Next.js requires 'unsafe-inline' for scripts due to framework architecture. For stricter CSP, consider migrating to nonce-based approach in future.
  • Completed: Dec 30, 2024

✅ 6. Redis-Based Rate Limiting

  • Status: ✅ Complete
  • Requirements:
    • Configure @nestjs/throttler storage adapter for Redis
    • Persist rate limit counters across restarts
    • Monitor Redis connection health
  • Testing: Restart API during rate limit period, verify limits persist
  • Implementation: RedisThrottlerStorage in backend/src/common/throttler/
  • Features:
    • Automatic fallback to in-memory when Redis unavailable
    • Reconnection logic with exponential backoff
    • Graceful degradation without service interruption
  • Completed: Dec 30, 2024

✅ 7. Password Strength Requirements

  • Status: ✅ Complete
  • Requirements:
    • Minimum 10 characters
    • Require mixed case, number, special character
    • Show password strength meter in UI
  • Testing: Try weak passwords, verify rejection with helpful feedback
  • Implementation:
    • Backend: IsStrongPassword validator in backend/src/common/validators/
    • Frontend: Real-time strength meter in registration form
    • Endpoint: POST /auth/password-strength for client-side validation
  • Features:
    • 5-level strength scoring system
    • Pattern detection (sequential, common passwords)
    • Clear visual feedback with checkmarks
    • Progressive disclosure on password field focus
  • Completed: Dec 30, 2024

✅ 8. Session Management UI

  • Status: ✅ Complete (MVP)
  • Requirements:
    • Endpoint to list active refresh tokens
    • Revoke current session
    • UI to view and manage sessions
  • Testing: Login, view sessions page, revoke session
  • Implementation:
    • Backend: SessionService in backend/src/auth/
    • Endpoints: GET /auth/sessions, DELETE /auth/sessions/current
    • Frontend: /dashboard/settings/sessions page
  • Features:
    • List active sessions with partial token hash
    • Show issue time and expiration
    • Mark current session
    • One-click revocation
    • Explicit loading, retryable error, and empty states so session review does not fail silently
  • Future Enhancements:
    • Store sessions in Redis/DB for multi-device tracking
    • Device fingerprinting (browser, OS, IP)
    • Email notification on new device login
    • Revoke all sessions except current
  • Completed: Dec 30, 2024

✅ 9. Audit Logging

  • Status: ✅ Complete
  • Requirements:
    • Log: account deletion, password changes, item deletion, location deletion
    • Include: userId, timestamp, IP, user agent, old/new values
    • Retention: 90 days minimum
    • Storage: Separate audit table (AuditLog)
  • Testing: Trigger each event, verify log entry in database
  • Implementation:
    • Service: AuditLogService in backend/src/common/audit/
    • Database: AuditLog model in Prisma schema
    • Integration: Auth, Items, Locations services
  • Features:
    • Automatic IP extraction (handles X-Forwarded-For, X-Real-IP)
    • Non-blocking audit writes (errors don't fail main operation)
    • Query methods for user/entity audit history
    • Cleanup method for 90-day retention
  • Logged Actions:
    • ACCOUNT_DELETED - User account deletion with email
    • PASSWORD_CHANGED - Password change events
    • ITEM_DELETED - Item deletion with name, location, tags
    • LOCATION_DELETED - Location deletion with name, parent
  • Future Enhancements:
    • Scheduled cron job for automated cleanup (every 30 days)
    • User-facing audit log viewer in settings
    • Export audit logs for compliance requests
    • Failed login attempt tracking
  • Compliance: Satisfies SOC2, GDPR data subject request requirements
  • Completed: Dec 30, 2024

⏳ 10. File Upload Scanning

  • Status: Not implemented
  • Requirements:
    • Integrate malware scanning (ClamAV, AWS Macie, Cloudflare)
    • Scan before confirming upload
    • Quarantine flagged files
    • Alert user on malicious upload attempt
  • Testing: Upload EICAR test file, verify rejection
  • Cost: Evaluate hosted scanning vs self-hosted

Medium Priority (Nice to Have)

11. Request ID Headers

  • Implementation: Add X-Request-ID to response headers
  • Benefit: User support can trace specific requests

12. Persistent Brute Force Detection

  • Implementation: Track failed logins per email in Redis
  • Benefit: Detect distributed attacks across IPs

✅ 13. Two-Factor Authentication (2FA)

  • Status: ✅ Complete
  • Implementation:
    • Prisma: Added twoFactor* fields on User plus TwoFactorChallenge table for pending logins
    • Service: TwoFactorService (Nest provider) using otplib for TOTP and SHA-256 hashed recovery codes
    • Endpoints: /auth/2fa/setup, /auth/2fa/verify, /auth/2fa/status, /auth/2fa/recovery-codes, /auth/2fa/disable, and /auth/2fa/challenge
    • Frontend: Login flow with challenge UI + settings page for setup, disable, and code regeneration with QR preview
  • Benefit: Required for premium/work accounts; mitigates credential stuffing even after password disclosure
  • Testing:
    • Enrol new user via /settings/security and confirm authenticator + recovery code download
    • Attempt login to ensure challenge is required, verify both TOTP and recovery code paths
    • Disable 2FA using password + code; confirm refresh tokens revoked and audit logs written

14. API Versioning Strategy

  • Documentation: Define deprecation timeline (maintain v1 for 6+ months)
  • Benefit: Safe breaking changes in future

15. Dependency Vulnerability Scanning

  • Implementation: GitHub Dependabot, Snyk, or pnpm audit in CI
  • Benefit: Automated security patch alerts

16. Enhanced Security Headers

  • Implementation: Add X-Frame-Options, Referrer-Policy, Permissions-Policy
  • Benefit: Defense in depth

For Paid Launch (Business Requirements)

✅ 17. Email Verification

  • Status: ✅ Complete
  • Requirements:
    • Send verification link on registration
    • Prevent throwaway accounts
    • Allow login but show banner until verified
  • Implementation:
    • Database: Added emailVerified, verificationToken, verificationTokenExpiry to User model
    • Service: EmailService in backend/src/common/email/
    • Endpoints: POST /auth/verify-email, POST /auth/resend-verification
    • Frontend: Verification page at /auth/verify-email
  • Features:
    • 24-hour token expiry
    • Secure random token generation (32 bytes hex)
    • Email templates with HTML/text versions
    • Resend verification with rate limiting (3/min)
    • Visual banner for unverified users
  • Email Service:
    • Development: Logs to console
    • Production: Ready for SendGrid/Mailgun/AWS SES/Resend integration
    • Configurable via EMAIL_FROM and FRONTEND_URL env vars
  • Testing: Register new account, check logs for verification link, verify token works
  • UX: Users can use app while unverified, banner prompts verification
  • Completed: Dec 30, 2024

✅ 18. Account Takeover Protection

  • Status: ✅ Complete
  • Requirements:
    • Revoke all active sessions on password change
    • Prevent attackers from maintaining access after user secures account
  • Implementation:
    • Database: RefreshToken table with tokenHash, expiresAt, lastUsedAt, ipAddress, userAgent
    • Service: Token validation in refresh flow against database
    • Automatic revocation: All refresh tokens deleted on password change
  • Features:
    • Refresh tokens stored in database (not just JWT)
    • SHA-256 hashing of tokens for secure storage
    • Token validation on every refresh request
    • Automatic cleanup of expired tokens
    • IP address and user agent tracking for sessions
  • Security:
    • After password change, all other devices/browsers logged out
    • Tokens validated against database (can't be used if revoked)
    • Expired tokens automatically deleted on refresh attempt
  • Testing: Change password in one browser, verify other sessions logged out
  • Completed: Dec 30, 2024

19. Payment Integration Security

  • Provider: Stripe or Paddle (PCI DSS compliant)
  • Never Store: Credit card numbers, CVV
  • Required:
    • Webhook signature verification
    • Idempotency keys for charges
    • Subscription state machine
    • Refund audit trail
  • Testing: Test mode transactions, webhook replays
  • Status: To be implemented

20. Legal & Compliance

  • Required Documents:
    • Privacy Policy (GDPR/CCPA compliant)
    • Terms of Service
    • Cookie Policy (EU users)
  • Required Features:
    • Data export (JSON download)
    • Complete account deletion (DB + S3 cleanup)
    • Cookie consent banner (EU)
  • Timeline: Complete before accepting payments

Pre-Deploy Checklist

Environment Setup

  • Generate production JWT secrets (48+ bytes, unique per env)
  • Set NODE_ENV=production
  • Set COOKIE_SECURE=true
  • Configure FRONTEND_ORIGIN with production domain(s)
  • Add ?sslmode=require to DATABASE_URL
  • Verify S3 bucket is private (no public read)
  • Configure proper IAM permissions for S3 access
  • Set up Redis with TLS enabled
  • Add startup validation for all required env vars

Monitoring & Logging

  • Configure error tracking (Sentry, Rollbar, etc.)
  • Set up structured log aggregation (Papertrail, Loggly, CloudWatch)
  • Create uptime monitoring (Pingdom, UptimeRobot)
  • Set up database backups (daily, 30-day retention)
  • Configure alerts for API errors, slow queries, high memory

Security Validation

  • Run pnpm audit in backend and frontend
  • Fix all critical and high vulnerabilities
  • Test CORS with production frontend origin
  • Verify CSRF token exchange works
  • Test file upload with max size limit
  • Confirm rate limiting blocks excessive requests
  • Test authentication flow (register, login, refresh, logout)
  • Verify password hashing with bcrypt cost 12

Staging Environment

  • Deploy to staging with production-like config
  • Run full E2E test suite
  • Manual QA on mobile devices
  • Load test with k6 or Artillery
  • Check browser console for CSP violations
  • Verify analytics events firing correctly

Pre-Paid Launch Checklist

Legal Foundation

  • Privacy policy drafted and reviewed
  • Terms of service drafted and reviewed
  • Cookie consent banner implemented
  • GDPR data subject request process documented

Payment Infrastructure

  • Stripe/Paddle account created
  • Webhook endpoints secured with signature verification
  • Test subscription flow (create, update, cancel)
  • Refund process documented
  • Failed payment retry logic implemented

Enhanced Security

  • Email verification flow complete
  • Password strength requirements enforced
  • Session management UI implemented
  • Audit logging capturing all sensitive actions
  • 2FA available for premium users (optional but recommended)

Data Protection

  • Data export feature tested
  • Account deletion removes all data (DB + S3)
  • Backup restoration tested
  • Encryption at rest verified for database

Ongoing Maintenance Schedule

Weekly

  • Review dependency updates (Dependabot PRs)
  • Check error tracking for new patterns
  • Monitor rate limit violations

Monthly

  • Review audit logs for anomalies
  • Update security documentation
  • Check for new CVEs in dependencies
  • Test backup restoration

Quarterly

  • Rotate JWT secrets in production
  • Review and update privacy policy
  • Penetration testing (self-service or external)
  • Review user feedback for security concerns

Annually

  • External security audit
  • Compliance review (GDPR, CCPA, SOC2 if applicable)
  • Disaster recovery drill

Incident Response Plan

Detection

  • Monitor error tracking for auth failures
  • Alert on unusual login patterns
  • Watch for sudden traffic spikes

Response Steps

  1. Confirm incident (false positive check)
  2. Assess scope (affected users, data exposure)
  3. Contain threat (revoke tokens, block IPs)
  4. Investigate root cause
  5. Remediate vulnerability
  6. Notify affected users (if data breach)
  7. Document lessons learned

Communication Templates

  • User notification email (data breach)
  • Status page update (service disruption)
  • Post-mortem report (internal)

Current Status Summary

Ready for Free/Beta Deploy:

  • Strong foundation with JWT auth, CSRF protection, input validation
  • Need to complete: env var validation, Redis rate limiting

Ready for Paid Launch:

  • All High Priority items (5-10) complete
  • Legal documents published
  • Payment integration tested
  • Audit logging operational

Target Timelines:

  • Beta launch: 1-2 weeks (Critical + items 4-6)
  • Paid launch: 4-6 weeks (all High Priority + Legal + Payment)

Decisions (Locked)

  • Use managed hosting (Render) with auto-SSL for initial launch
  • Prioritize session management over 2FA for MVP
  • Start with Stripe for payment processing
  • Maintain audit logs in Postgres for first year (evaluate external service later)
  • Defer CSP to post-beta (track separately)