Security Checklist Before Going to Production

Unencrypted HTTP traffic can be intercepted, modified, or injected by anyone on the network path between your server and your users. Every production application must serve all content exclusively over HTTPS with a valid, trusted TLS certificate.

• Obtain and install a valid TLS certificate from a trusted Certificate Authority (CA) — Let's Encrypt provides free, auto-renewing certificates.
• Force HTTPS by redirecting all HTTP requests (port 80) permanently to HTTPS (port 443) with a 301 redirect.
• Disable obsolete TLS versions (TLS 1.0 and TLS 1.1); accept only TLS 1.2 and TLS 1.3.
• Remove weak and deprecated cipher suites from your server configuration; prefer AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305).
• Enable OCSP stapling on your web server to speed up certificate revocation checks.
• Verify your certificate covers all subdomains in use (wildcard or SAN certificate where needed).
• Set a certificate expiry reminder at least 30 days before expiration to avoid unplanned downtime. Sensagraph continuously monitors your certificate validity and alerts you before it expires.

HTTP response headers are one of the fastest wins in web security. Correctly configured headers instruct the browser to enforce policies that mitigate cross-site scripting (XSS), clickjacking, MIME sniffing, and data leakage — often with a single line of server configuration. Sensagraph checks all major security headers automatically on every scan.

• Strict-Transport-Security (HSTS): Set Strict-Transport-Security: max-age=31536000; includeSubDomains; preload to enforce HTTPS at the browser level.
• Content-Security-Policy (CSP): Define a strict CSP that whitelists only the sources your application legitimately loads scripts, styles, images, and fonts from. Avoid unsafe-inline and unsafe-eval wherever possible.
• X-Frame-Options: Set to DENY or SAMEORIGIN to prevent clickjacking by blocking your pages from being embedded in third-party iframes.
• X-Content-Type-Options: Set to nosniff to prevent browsers from MIME-sniffing responses away from the declared content type.
• Referrer-Policy: Set to strict-origin-when-cross-origin or stricter to control how much referrer information is sent with requests.
• Permissions-Policy: Restrict access to browser features (camera, microphone, geolocation) that your application does not use.
• Remove or suppress server banner headers that disclose your web server software and version (e.g., Server, X-Powered-By).

Weak authentication is the most common entry point for attackers. Before launch, verify that every authentication mechanism is implemented correctly and that sessions cannot be hijacked or forged.

• Store passwords using a strong, slow hashing algorithm: bcrypt, scrypt, or Argon2. Never use MD5, SHA-1, or unsalted SHA-256 for passwords.
• Enforce a minimum password length of at least 12 characters and check new passwords against known-breached password lists (e.g., using the Have I Been Pwned API).
• Implement multi-factor authentication (MFA) for all administrative accounts and offer it as an option for regular users.
• Set session cookies with the HttpOnly, Secure, and SameSite=Lax (or Strict) attributes.
• Regenerate the session ID after a successful login to prevent session fixation attacks.
• Set a sensible session timeout (e.g., 15–30 minutes of inactivity for sensitive applications) and provide a logout function that fully invalidates the server-side session.
• Implement account lockout or progressive delays after repeated failed login attempts to resist brute-force attacks.
• Ensure password reset flows use short-lived, single-use tokens sent to a verified email address — not security questions.
• Protect all authentication endpoints with CSRF tokens or use the SameSite cookie attribute as a primary CSRF defence.

Injection vulnerabilities — SQL injection, command injection, XSS, XML injection, and others — remain among the most dangerous and prevalent weaknesses in web applications. Every piece of data that enters your application from the outside world must be treated as untrusted.

• Use parameterized queries or prepared statements for every database interaction — never concatenate user input directly into SQL strings.
• Apply an ORM's built-in query-building methods rather than raw query construction wherever possible.
• Validate input on the server side for type, length, format, and range — client-side validation is a UX aid, not a security control.
• Encode all user-supplied output before rendering it in HTML, JavaScript, CSS, or URL contexts to prevent XSS.
• If you must accept rich HTML from users, use an allowlist-based HTML sanitization library (e.g., DOMPurify) rather than a blocklist.
• Validate and restrict file upload types, sizes, and storage locations; never execute uploaded files or store them within the web root.
• Sanitize data used in shell commands, LDAP queries, XPath queries, and any other structured interpreter to prevent injection in those contexts.

Broken access control is consistently ranked as the top web application vulnerability. Every action in your application should be governed by an explicit, server-enforced authorization check — never rely on obscurity or client-side controls alone.

• Apply the principle of least privilege: users, services, and processes should have only the permissions they genuinely need.
• Enforce authorization checks on every server-side endpoint, including API routes — do not assume a route is safe because it is not linked in the UI.
• Use indirect object references (e.g., UUIDs, opaque tokens) instead of sequential database IDs to reduce the risk of Insecure Direct Object Reference (IDOR) attacks.
• Restrict administrative interfaces to specific IP ranges or a VPN, and never expose them on the public internet.
• Implement role-based access control (RBAC) or attribute-based access control (ABAC) and test every role's permissions before launch.
• Deny access by default: if a user's authorization for a resource cannot be positively confirmed, deny the request.
• Verify that directory listing is disabled on your web server so that file and directory structures are not publicly browsable.

Development environments accumulate secrets, verbose error messages, and debug tooling that are invaluable during development but catastrophic in production. A single exposed stack trace or hardcoded API key can give an attacker everything they need.

• Disable debug mode in your application framework (e.g., DEBUG=False in Django, app.debug = False in Flask).
• Replace verbose error pages with generic, user-friendly error messages in production; log full stack traces server-side only.
• Remove all hardcoded credentials, API keys, tokens, and secrets from source code; store them in environment variables or a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager).
• Audit your repository history for accidentally committed secrets using tools like git-secrets or truffleHog, and rotate any exposed credentials immediately.
• Remove development-only routes, admin backdoors, and test accounts before deploying to production.
• Ensure your .env files, configuration files, and any files containing secrets are excluded from version control via .gitignore.
• Check that backup files, source archives, and editor swap files (e.g., .bak, .swp, ~) are not accessible from the web root.

Modern applications rely heavily on open-source libraries and packages. Each dependency you include extends your attack surface — a vulnerability in a single unmaintained library can compromise your entire application. Sensagraph surfaces publicly known vulnerabilities in technologies detected on your site.

• Run a dependency audit using your package manager's built-in tool (npm audit, pip-audit, bundler-audit, composer audit, etc.) and resolve all critical and high-severity findings.
• Pin dependency versions in your lockfile and commit the lockfile to version control to ensure reproducible builds.
• Remove unused dependencies entirely — every extra package is additional attack surface and maintenance burden.
• Subscribe to security advisories for your major dependencies (GitHub Dependabot, OSS Index, or similar).
• Prefer well-maintained, widely-used libraries over obscure ones for security-critical functionality such as cryptography, authentication, and input parsing.
• Verify the integrity of packages where possible using package signing or checksum verification.

Even a perfectly written application can be compromised by a poorly configured server. Harden the underlying infrastructure before your application goes live, and minimize the attack surface at every layer.

• Close all ports that are not required for the application to function using a firewall (e.g., UFW, iptables, or a cloud security group). Expose only ports 80 and 443 to the public internet.
• Disable remote root login via SSH; use key-based authentication only and disable password-based SSH login.
• Keep the operating system and all installed packages up to date with security patches; enable automatic security updates where practical.
• Run your web application process as a dedicated, unprivileged user — never as root.
• Configure your web server to hide version banners (e.g., ServerTokens Prod in Apache, server_tokens off in Nginx).
• Disable unused web server modules and features (e.g., WebDAV, directory listing, server-side includes) to reduce the attack surface.
• Implement rate limiting on all public-facing endpoints to mitigate brute-force and denial-of-service attempts.
• Use a Web Application Firewall (WAF) in front of your application to filter common attack patterns.
• Ensure database servers, caches, and internal services are not directly reachable from the public internet — place them on a private network.

You cannot respond to what you cannot see. Comprehensive logging and real-time monitoring are essential for detecting attacks in progress, investigating incidents after the fact, and meeting compliance obligations. Set these up before you go live, not after your first breach.

• Log all authentication events: successful logins, failed logins, password resets, and MFA challenges — include timestamps and source IP addresses.
• Log all access control failures (403 responses) and unexpected application errors (500 responses).
• Store logs in a centralized, write-protected location that is separate from the application server so that an attacker who compromises the web server cannot tamper with logs.
• Set up real-time alerts for anomalous patterns: repeated failed logins, unusual spikes in traffic, access to sensitive endpoints, or errors from unexpected IP ranges.
• Do not log sensitive data such as passwords, full credit card numbers, session tokens, or personal data in plain text.
• Define and test an incident response plan before launch so your team knows what to do when an alert fires.
• Establish a log retention policy that satisfies your regulatory obligations (e.g., 90 days minimum for many compliance frameworks).

Manual checklists catch a great deal, but automated scanning provides systematic, repeatable coverage across your entire application surface — finding vulnerabilities that are easy to overlook under pre-launch pressure. This should be the final gate before every production release.

• Scan your staging or pre-production environment, which should be as close to production as possible, before deploying the final release.
• Review all findings from the scan, triage them by severity, and remediate critical and high findings before launch — do not defer them as "post-launch tech debt."
• Check that your application does not expose sensitive paths such as /.git, /.env, /admin, backup archives, or API documentation intended only for internal use.
• Verify that error pages for 404, 403, and 500 responses do not leak technology stack information.
• Confirm that all endpoints use the correct HTTP methods and reject unexpected ones (e.g., a login endpoint should not accept PUT or DELETE).
• Schedule automated scans to run on a recurring basis after launch — security is not a one-time event. Sensagraph continuously monitors your live site and alerts you as new issues are discovered.