Pre-Launch Security Checklist for a New Website

Unencrypted HTTP exposes your users to eavesdropping, credential theft, and content injection. A valid TLS certificate is the baseline for any modern site — not optional.

• Obtain a valid TLS certificate (Let's Encrypt, your hosting provider, or a commercial CA) and install it on every domain and subdomain you serve.
• Redirect all HTTP traffic (port 80) to HTTPS (port 443) with a permanent 301 redirect — do this at the web server level, not only in application code.
• Verify the certificate covers all subdomains you intend to use (wildcard or individual SANs).
• Check the certificate expiry date and set up automatic renewal so it never lapses.
• Confirm there are no mixed-content warnings in the browser console — every asset (images, scripts, fonts, iframes) must load over HTTPS.
• Enable HTTP Strict Transport Security (HSTS) so browsers refuse to connect over plain HTTP even if a redirect is somehow missing (see Step 02).

Security headers are instructions your server sends to the browser. They are one of the fastest wins in web security — a few lines of server config can block entire classes of attack. Sensagraph automatically checks for missing or misconfigured security headers on your site.

• Strict-Transport-Security (HSTS): Set max-age to at least 31536000 (one year); add includeSubDomains once you are confident all subdomains support HTTPS. Consider adding preload and submitting to the HSTS preload list.
• Content-Security-Policy (CSP): Define a policy that whitelists only the origins you intentionally load scripts, styles, and media from. Start in report-only mode, review violations, then enforce.
• X-Frame-Options: Set to DENY or SAMEORIGIN to prevent clickjacking.
• X-Content-Type-Options: Set to nosniff to stop browsers guessing MIME types.
• Referrer-Policy: Set to strict-origin-when-cross-origin or stricter to avoid leaking URLs in the Referer header.
• Permissions-Policy: Disable browser features you do not use (camera, microphone, geolocation, etc.).
• Remove or suppress headers that leak server technology, such as X-Powered-By and Server.

Weak authentication is one of the leading causes of website compromise. Lock down every account — admin, deployment, database, and end-user — before launch.

• Enforce strong password requirements (minimum 12 characters, no common passwords) or, better yet, use a passphrase policy aligned with NIST SP 800-63B.
• Enable multi-factor authentication (MFA) for all admin and privileged accounts — use TOTP apps rather than SMS where possible.
• Change every default credential: CMS admin usernames and passwords, database users, hosting control panels, and SSH keys.
• Apply the principle of least privilege — each user account and service should have only the permissions it actually needs.
• Implement account lockout or rate limiting after repeated failed login attempts to slow credential-stuffing attacks.
• Ensure password reset flows use time-limited, single-use tokens sent to a verified address and do not leak whether an email is registered.
• Store passwords using a strong adaptive hash function (bcrypt, Argon2, or scrypt) — never MD5, SHA-1, or plain SHA-256 alone.
• If you use OAuth or SSO, verify redirect URIs are explicitly whitelisted and tokens are validated correctly.

Injection vulnerabilities — SQL injection, Cross-Site Scripting (XSS), command injection, and path traversal — remain the most exploited web flaws. They all share the same root cause: trusting user-supplied data.

• Use parameterised queries or prepared statements for every database interaction — never concatenate user input into SQL strings.
• Apply an allowlist (not just a denylist) to validate every form field: expected type, length, format, and range.
• Encode output correctly for its context — HTML-encode data rendered in HTML, JSON-encode for JSON responses, URL-encode for query parameters.
• Use your framework's built-in XSS protection and template auto-escaping; never disable it without a documented reason.
• Sanitize file upload names and validate MIME types server-side; store uploaded files outside the web root or in an object storage bucket with no execute permissions.
• Prevent path traversal by resolving file paths with a canonical function and confirming they remain inside the intended directory.
• Test every input field, URL parameter, and HTTP header your application processes — these are all attack surfaces.

Modern websites rely on dozens of open-source packages and third-party scripts. Each one is a potential entry point. Audit them before launch, not after an incident.

• Run npm audit, composer audit, pip-audit, or the equivalent for your language ecosystem and resolve all high and critical vulnerabilities before launch.
• Pin dependency versions in your lock file (package-lock.json, composer.lock, etc.) so updates do not silently introduce new code.
• Review every third-party JavaScript tag loaded in the browser (analytics, chat widgets, ad networks) — each one runs with full access to the page. Use Subresource Integrity (SRI) hashes for scripts loaded from CDNs.
• Remove unused dependencies entirely — every extra package is attack surface you don't need.
• Set up a dependency scanning tool in your CI pipeline so new vulnerabilities are caught automatically on future updates.
• Check that your CMS, framework, and any plugins are on the latest stable release and have no known unpatched CVEs.

Application-level security is undermined if the underlying server is poorly configured. Treat the server as part of your attack surface.

• Disable or remove all services, ports, and daemons that are not required — close every port that doesn't need to be open to the internet.
• Configure a firewall to allow only necessary inbound traffic (typically 80, 443, and a non-default SSH port).
• Disable SSH password authentication and use key-based authentication only; move SSH to a non-standard port as an additional low-cost deterrent.
• Keep the operating system and all server software (web server, PHP-FPM, Node runtime, etc.) patched and up to date.
• Run your application process as a non-root, low-privilege user.
• Disable web server features that expose information: server tokens, version banners, and directory listing.
• If using a cloud provider, audit your security group / firewall rules, IAM roles, and bucket policies — public S3 buckets with sensitive content are a common misconfiguration.

Overly permissive file permissions are a quiet risk — they let attackers read configuration files or write malicious scripts if they gain a foothold elsewhere.

• Confirm web-accessible directories do not allow directory listing (return 403 or 404 for bare directory requests, not an index of files).
• Ensure .env, config.php, database credentials, private keys, and any secrets file are not accessible via a public URL — test this directly in a browser.
• Set file permissions so the web server process can read application files but cannot write to them unless your application explicitly requires it.
• Keep .git, .svn, composer.json, package.json, backup files (*.bak, *.sql), and log files outside the web root or blocked in server config.
• Verify that sensitive admin routes or staging URLs are not publicly indexed — use robots.txt carefully (it is public) and prefer authentication or IP restriction for staging environments.

Session hijacking and cookie theft are trivial when cookies are not properly configured. Getting this right protects every authenticated user on your site.

• Set the Secure flag on all cookies so they are never sent over plain HTTP.
• Set the HttpOnly flag on session and authentication cookies to prevent JavaScript from reading them (mitigating XSS-based theft).
• Set the SameSite attribute to Strict or Lax to prevent Cross-Site Request Forgery (CSRF) via cookie leakage.
• Use long, randomly generated, cryptographically secure session identifiers — never expose predictable IDs.
• Regenerate the session ID after a successful login to prevent session fixation attacks.
• Set appropriate session timeout values and implement idle session expiry for sensitive applications.
• Include CSRF tokens on all state-changing forms and API endpoints that rely on cookie-based authentication.

Verbose error messages are a gift to attackers — they reveal stack traces, file paths, database schemas, and technology versions. At the same time, good logging is your best forensic tool when something does go wrong.

• Switch your application to production mode before launch — disable debug mode, stack trace output, and detailed error pages for public visitors.
• Show users a generic, friendly error page (500, 404, etc.) while logging the full technical detail server-side only.
• Log authentication events: successful logins, failed attempts, password resets, and account lockouts.
• Log access to sensitive actions: admin operations, data exports, permission changes.
• Ensure log files are written to a location outside the web root and are not accessible via URL.
• Set up log rotation and retention policies so logs are available for incident investigation but do not grow unbounded.
• Consider shipping logs to a centralised log management service so they are preserved even if the server is compromised.

DNS misconfigurations and missing email authentication records allow attackers to impersonate your domain, intercept traffic via subdomain takeover, or send phishing emails that appear to come from you.

• Add an SPF record for your domain to specify which mail servers are allowed to send on your behalf.
• Configure DKIM signing for all outbound email streams.
• Publish a DMARC policy — start with p=none to collect reports, then tighten to quarantine or reject once you have visibility.
• Audit your DNS records for dangling CNAMEs pointing to services you no longer use — these can be hijacked for subdomain takeover.
• Enable DNSSEC on your domain if your registrar supports it.
• Ensure your domain registrar account uses a strong password and MFA — a stolen domain is catastrophic.
• Review all subdomains for services that have been deprovisioned but still have DNS records pointing at them.

Manual checklists catch many issues, but automated scanning finds the ones you missed — misconfigurations, exposed endpoints, weak TLS settings, and known vulnerabilities. Run a scan after completing all the steps above, fix everything flagged, and then go live. Sensagraph continuously scans your site for the issues covered in this checklist, giving you an up-to-date view of your security posture from day one.

• Scan the full site including all subdomains, not just the homepage.
• Verify TLS configuration: protocol versions, cipher suites, certificate chain, and HSTS behaviour.
• Check all security headers are present and correctly configured.
• Test for common web vulnerabilities: open redirects, information disclosure pages, exposed admin interfaces, and directory listing.
• Review the scan report and fix every high and critical finding before publishing your DNS records or announcing the launch.
• Schedule ongoing automated scans post-launch so new issues introduced by updates or content changes are caught quickly.