Security Checklist Before Production Deployment: 25 Points

Moving code to production is where security failures have real consequences. A security issue caught in code review costs minutes to fix; the same issue in production can cost weeks of incident response, regulatory notification obligations, and irreversible reputational damage. This checklist provides 25 concrete control points organized across five domains, aligned with OWASP, NIST SP 800-53, and CIS Benchmarks.

The checklist is designed to be run before every significant production deployment. For continuous deployment pipelines, it should be encoded as automated checks where possible and as manual gates for controls that require human judgment.

Domain 1 — Infrastructure (5 Points)

1. TLS everywhere

All communications between clients and servers, and between internal services, must use TLS 1.2 minimum, TLS 1.3 preferred. Verify:

• Certificate validity and expiry (automate renewal with Let's Encrypt or equivalent)
• No HTTP endpoints accessible on public interfaces
• TLS version and cipher suite configuration audited (use Mozilla's SSL Configuration Generator)
• Certificate pinning considered for mobile clients handling sensitive data

2. Firewall and network segmentation

Production systems must be isolated from development and staging environments. Verify:

• Only required ports are open (80/443 for web, 22 for SSH limited to known IPs or VPN)
• Database ports (5432 for PostgreSQL, 3306 for MySQL) not accessible from the public internet
• Internal services communicate over private network only
• Security groups or firewall rules reviewed and documented

3. Server hardening

Apply OS-level hardening before workloads go live. Verify:

• Unnecessary services and packages removed
• SSH root login disabled; key-based authentication enforced
• System packages up to date (especially kernel and OpenSSL)
• Fail2ban or equivalent rate limiting on SSH and admin interfaces
• Principle of least privilege for service accounts

4. Container and image security

For containerized deployments, verify:

• Base images are official and pinned to specific digest hashes, not :latest tags
• No secrets in Dockerfiles or image layers (use build secrets or runtime env injection)
• Container runtime configured with restricted capabilities (no --privileged in production)
• Image vulnerability scan completed (tools: Trivy, Snyk, Docker Scout) — critical CVEs resolved

5. Secrets management

Production secrets (API keys, database credentials, signing keys) must never be stored in source code, environment files committed to version control, or logs. Verify:

• All secrets injected at runtime via environment variables, a dedicated secret manager (AWS Secrets Manager, HashiCorp Vault, Infisical), or equivalent
• .env files in .gitignore; git history scanned for accidental commits (tools: TruffleHog, git-secrets)
• Secret rotation policy documented and tested
• No hardcoded credentials in any source file

Domain 2 — Application Security (5 Points)

6. Input validation and sanitization

Every input reaching your application from an external source — HTTP parameters, JSON bodies, file uploads, webhook payloads — must be validated. Verify:

• Schema validation on all API request bodies (Zod, Joi, Pydantic, or equivalent)
• File type validation by content (magic bytes), not by extension alone
• Maximum size limits enforced on all inputs
• SQL queries use parameterized statements or ORM; no string concatenation in queries (OWASP A03:2021)

7. XSS protections

Cross-site scripting remains in the OWASP Top 10 (A03:2021). Verify:

• Output encoding applied for all user-controlled content rendered in HTML
• Content Security Policy (CSP) header configured and tested — see our guide on secure HTTP headers
• Raw HTML injection patterns (direct DOM manipulation with unescaped content) are audited; DOMPurify or equivalent applied where unavoidable
• Stored content (e.g., user-generated notes, comments) sanitized before storage and on render

For a deeper treatment, see our XSS protection complete guide.

8. Dependency audit

Third-party dependencies are the most common source of supply chain vulnerabilities. Verify:

• npm audit, pnpm audit, pip-audit, or equivalent run and high/critical issues resolved
• No packages from deprecated or unmaintained repositories
• Lock file (package-lock.json, pnpm-lock.yaml) committed and reflects production dependencies
• Dependabot or Renovate configured for automated dependency updates in staging

9. Error handling and information disclosure

Production error responses must not expose internal details. Verify:

• Stack traces never returned to clients (configure production error middleware)
• Generic error messages for all 5xx responses
• Verbose database errors caught and replaced before response
• Debug endpoints and development tools disabled in production builds (GraphQL introspection, Swagger UI with write access, /health with internal system details)

10. Security headers

HTTP response headers are a low-cost, high-impact security control. Verify the following headers are present and correctly configured:

• Strict-Transport-Security (HSTS) with minimum max-age=31536000
• Content-Security-Policy restricting script sources
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY or SAMEORIGIN
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy restricting browser feature access

Use securityheaders.com or OWASP ZAP to verify header configuration.

Domain 3 — Authentication and Authorization (5 Points)

11. Password and credential policies

Verify:

• Passwords stored using bcrypt, scrypt, or Argon2 — never MD5 or SHA-1
• Minimum password length enforced (12 characters minimum, NIST SP 800-63B)
• Account lockout or rate limiting after repeated failed attempts
• Password reset flow uses time-limited, single-use tokens sent to verified contact

12. Session management

Verify:

• Session tokens are cryptographically random (minimum 128 bits of entropy)
• Sessions invalidated on logout (server-side invalidation, not just cookie deletion)
• Session timeout configured (idle timeout 30 minutes for sensitive applications)
• HttpOnly and Secure flags set on session cookies; SameSite=Strict or SameSite=Lax

13. Multi-factor authentication

For any application handling sensitive data or administrative functions, verify:

• MFA available and enforced for administrative accounts
• MFA strongly encouraged (and ideally required) for user accounts handling sensitive data
• Recovery codes generated and securely delivered at MFA enrollment

14. Authorization model

Horizontal and vertical privilege escalation (OWASP A01:2021 — Broken Access Control) is the leading application security risk. Verify:

• Every API endpoint and server action checks authorization before returning data or executing actions
• Authorization checks performed server-side, not inferred from client-sent user identifiers
• Object-level authorization checked: user A cannot access user B's resources by guessing an ID
• Admin functionality requires explicit role check; role assignment restricted to authorized users only

15. OAuth and third-party auth

If using OAuth 2.0 or OIDC (social login, SSO), verify:

• state parameter used to prevent CSRF in OAuth flows
• redirect_uri validated against allowlist
• Tokens not logged or exposed in URLs
• Token refresh rotation implemented for long-lived sessions

Domain 4 — Data Protection (5 Points)

16. Data classification

Verify:

• Sensitive data types (PII, financial data, health data, credentials) identified in your data model
• Data classification documented and accessible to the development team
• No sensitive data in logs, analytics payloads, or error reports (GDPR Article 5(1)(f), NIST CSF ID.AM)

17. Encryption at rest

Verify:

• Database encryption at rest enabled (PostgreSQL with encrypted volume or transparent data encryption)
• Sensitive fields (social security numbers, payment card data, health records) encrypted at the application layer in addition to disk-level encryption
• Encryption keys stored separately from encrypted data; key rotation process documented

18. Backup and recovery

Verify:

• Automated backups configured for production databases
• Backup restoration tested within the last 30 days
• Backups stored in a separate geographic region or account from production
• Retention period documented and aligned with regulatory requirements (GDPR data minimization)

19. Data minimization

Verify:

• Only data necessary for the stated purpose is collected (GDPR Article 5(1)(c))
• Retention periods defined and automated deletion or anonymization configured
• Staging and development environments do not use real production data (or use properly anonymized copies)

20. Third-party data flows

Verify:

• All services receiving personal data are listed in your Article 30 ROPA
• Data processing agreements (DPAs) in place for all processors
• International transfers documented with appropriate legal mechanism (SCC + TIA for US services)

Domain 5 — Monitoring and Response (5 Points)

21. Centralized logging

Verify:

• Application logs centralized and retained for minimum 90 days (365 days for compliance-sensitive applications)
• Log ingestion from all services confirmed (no silent gaps)
• Logs include sufficient context: timestamps, user/session identifiers, action performed, outcome
• Logs accessible without production system access (log forwarding to SIEM or log management platform)

22. Alerting on security events

Verify:

• Alerts configured for: repeated authentication failures, privilege escalation attempts, unusual data access volumes, configuration changes
• Alerting tested — verify alerts actually fire by simulating events
• Alert routing documented: who receives which alert, at what time, via which channel

23. Error monitoring

Verify:

• Runtime error tracking configured (Sentry, Datadog, or equivalent)
• New error categories trigger notifications to the development team
• Error rates baselined so anomalies are detectable

24. Incident response plan

Verify:

• Written incident response plan exists covering: detection, containment, eradication, recovery, post-incident review
• Under GDPR, the plan includes 72-hour supervisory authority notification and communication to affected data subjects where required
• Under the AI Act (for AI-enabled systems), serious incident reporting to providers is defined
• Plan tested at minimum annually via tabletop exercise

25. Vulnerability disclosure

Verify:

• A security.txt file or equivalent published at /.well-known/security.txt with contact details for responsible disclosure
• Internal process defined for triaging and remediating reported vulnerabilities
• Patch SLA defined: critical vulnerabilities patched within 48 hours, high within 7 days

Using This Checklist

This checklist works best as a gate in your deployment pipeline, not a post-hoc audit. For each control:

• Automated: Encode in CI/CD (dependency scanning, header testing, secret detection)
• Semi-automated: Run as a manual script before release (TLS check, firewall rule review)
• Manual gate: Require sign-off from a responsible person (authorization model review, incident plan test)

Document the result of each check, who performed it, and when. This record is evidence of due diligence in the event of a security incident, a regulatory audit, or a customer security review.

How WarDek Supports Pre-Deployment Security

WarDek's security scanning module automates checks across all five domains. Before each production release, WarDek runs header verification, dependency audits, configuration validation, and generates a signed pre-deployment report. The report satisfies customer security review requirements and provides documented evidence of your security posture.

Run your first pre-deployment scan with WarDek — results in under 3 minutes.

Key Takeaways

Security is a checklist problem as much as it is a technical one. The most common pre-production failures — hardcoded secrets, missing authorization checks, absent security headers, unpatched dependencies — are not exotic. They are systematic omissions caught by process. Run this checklist before every significant deployment. Automate what you can. The 25 points here cover the controls that prevent the majority of breach incidents reported to European supervisory authorities each year.

For related reading, see our guide on secure HTTP headers configuration and our complete XSS protection guide.