The Gap Between "It Works" and "It's Ready"
Shipping to production feels like crossing a finish line. It isn't. A working application and a production-ready application are fundamentally different things and the distance between them is precisely where incidents are born.
Deadline pressure, cognitive overload, and sheer familiarity with a codebase create dangerous blind spots. Even experienced developers skip critical checks — not from carelessness but from the false confidence that comes with functional code. This checklist covers 12 overlooked but high-impact items that stand between a clean deployment and a costly incident.
The Pre-Production Security Checklist Every Developer Should Run
1. Hardcoded Secrets and Exposed Environment Variables
API keys, database passwords, and tokens embedded directly in source code represent one of the most damaging oversights before a production push. A single accidental commit exposes credentials to anyone with repository access. Use git-secrets or truffleHog to audit your commit history and adopt secrets management via HashiCorp Vault or AWS Secrets Manager before going live.
2. Missing HTTP Security Headers
Headers like Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and X-Content-Type-Options actively mitigate clickjacking, MIME sniffing, and cross-site scripting attacks. Omitting them leaves documented vulnerabilities open with zero effort required from an attacker. Run your domain through securityheaders.com and treat a failing grade as a deployment blocker.
3. Debug Mode Left Enabled in Production
A verbose error message is a developer's best friend locally but an attacker's roadmap in production. Stack traces expose file paths, framework versions, and application logic. Laravel's APP_DEBUG=true, Django's DEBUG = True, and unfiltered Express error middleware are common culprits. Enforce silent, user-friendly error handling through environment-specific configuration before shipping.
4. Unvalidated and Unsanitized User Input
Client-side validation is a UX feature. Server-side validation is a security requirement. Treating user input as trustworthy opens the application to SQL injection, XSS, and command injection. Parameterized queries, ORM-safe data handling, and output encoding libraries are non-negotiable on any route that accepts external data.
5. Outdated or Vulnerable Dependencies
Third-party packages accelerate development but they introduce risk that is easy to ignore. The log4shell vulnerability compromised thousands of applications through a single widely-used logging library. Run npm audit, pip-audit, or snyk test before every production deployment and treat high-severity findings as release blockers rather than backlog items.
6. No Rate Limiting on API Endpoints
An unprotected authentication endpoint is an open invitation for brute-force attacks and credential stuffing. Without rate limiting, attackers can test thousands of password combinations in minutes. Implement express-rate-limit for Node.js applications or NGINX's limit_req directive for server-level enforcement before your API reaches the public internet.
7. Overly Permissive CORS Configuration
Setting Access-Control-Allow-Origin: * on authenticated endpoints allows any origin to read credentialed responses and that is an exploitable data exposure risk. Whitelist specific verified domains and never apply the wildcard header to routes returning user-specific or sensitive data.
8. Insufficient Logging and Monitoring
You cannot defend what you cannot observe. Authentication failures, permission denials, data mutations, and error spikes all require structured capture and real-time alerting. Integrate Datadog, Logtail, or Sentry with configured alerting thresholds before go-live — not after the first incident reveals the gap.
9. Excessive Database Privileges
Application database users rarely need DROP, ALTER, or GRANT rights but they frequently have them. The principle of least privilege limits the blast radius of a compromised credential significantly. Provision a dedicated application user with scoped read/write access only and keep migration credentials entirely separate.
10. Unforced HTTPS and Mixed Content
An SSL certificate alone does not enforce encrypted connections. Unconfigured HTTP-to-HTTPS redirects allow plaintext traffic and mixed content warnings indicate partial encryption failures. Configure server-wide 301 redirects and implement HSTS with an adequate max-age value to guarantee all traffic travels securely.
11. Unprotected Admin Routes and Internal Endpoints
Routes like /admin, /metrics, and /health are predictable, high-value targets. Leaving them publicly accessible without authentication is the server-side equivalent of labeling your spare key. Enforce IP allowlisting, require authentication middleware, or move admin surfaces behind a VPN entirely.
12. No Rollback or Disaster Recovery Plan
A rollback plan is not just an operational concern — it is a security consideration. A compromised or broken deployment without a tested recovery path extends the incident window with every passing minute. Tag every release, document a verified rollback procedure, and confirm backup integrity before shipping.
Ship with Confidence, Not Just Speed
Every item on this list represents a real incident waiting to happen. Collectively they describe the gap between code that works and code that is genuinely ready for production. Bookmark this checklist and run it before every deployment — not just the ones that feel risky. The deployments that feel routine are often the ones that aren't.