Website Security Checklist
Hardening your infrastructure: HTTPS, CSP, HTTP Headers, and XSS Prevention.
Security is not an add-on; it is a fundamental pillar of web development. A single vulnerability can lead to data breaches, compromised infrastructure, destroyed user trust, and significant legal liability. Launching a website without a rigorous security review is professional negligence.
This technical checklist expands on the security phase outlined in our Ultimate Website Launch Checklist. It provides actionable, developer-focused steps to harden your application against common attack vectors before exposing it to the public internet.
Related Technical Guides:
1. The Bedrock: Encryption in Transit
Unencrypted traffic is vulnerable to eavesdropping and Man-in-the-Middle (MitM) attacks. Encrypting traffic between the client and server is step zero.
Enforce HTTPS Everywhere
Obtain and install an SSL/TLS certificate (e.g., via Let's Encrypt). Configure your web server (Nginx, Apache, or your hosting provider) to permanently redirect all HTTP (`port 80`) traffic to HTTPS (`port 443`) using a `301 Moved Permanently` status code. No page, asset, or API endpoint should be accessible via plain HTTP.
Implement HTTP Strict Transport Security (HSTS)
Once HTTPS is enforced, add the `Strict-Transport-Security` header. This instructs the browser to *only* ever communicate with your domain over HTTPS for a specified duration (usually 1 year: `max-age=31536000`). This prevents attackers from forcing a protocol downgrade to HTTP during the initial connection attempt. Include the `includeSubDomains` directive if applicable.
Secure Cookies
If your application issues cookies (especially session identifiers), ensure they are transmitted securely. Set the `Secure` flag on all sensitive cookies so they are never sent over an unencrypted connection. Additionally, set the `HttpOnly` flag to prevent client-side JavaScript from accessing the cookie, mitigating the risk of session hijacking via XSS.
2. Defending Against Injection (XSS & SQLi)
Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands.
Cross-Site Scripting (XSS) Prevention
XSS occurs when an application includes untrusted data in a web page without proper validation or escaping. If an attacker can inject malicious JavaScript, they can steal session cookies, deface the site, or redirect users. Defend against XSS by strictly validating input on the server, and contextually encoding output before rendering it in the DOM (e.g., using HTML entity encoding).
SQL Injection (SQLi) Prevention
Never concatenate user input directly into SQL query strings. Always use prepared statements (parameterized queries) or an Object-Relational Mapper (ORM). Prepared statements ensure that the database treats user input strictly as data, not as executable SQL commands, completely neutralizing SQL injection vulnerabilities.
3. Hardening via HTTP Security Headers
Modern browsers offer powerful built-in security mechanisms that are activated via specific HTTP response headers. Implement these headers to drastically reduce your attack surface.
Content Security Policy (CSP)
The `Content-Security-Policy` header is your strongest defense against XSS and data injection. It allows you to create an explicit whitelist of domains from which your site is allowed to load resources (scripts, styles, images, fonts). A strict CSP prevents inline scripts (`<script>...</script>`) and blocks the execution of malicious scripts injected by attackers. Use our CSP Generator to build your policy.
X-Frame-Options (Clickjacking Protection)
Prevent attackers from embedding your site within a hidden `<iframe>` on a malicious site to trick users into clicking buttons (clickjacking). Set the `X-Frame-Options` header to `DENY` (blocks all framing) or `SAMEORIGIN` (allows framing only by pages on your own domain).
X-Content-Type-Options (MIME Sniffing Prevention)
Set `X-Content-Type-Options: nosniff`. This prevents the browser from trying to guess the MIME type of a file (e.g., treating a file uploaded as an image as an executable script). It forces the browser to strictly honor the `Content-Type` header provided by the server.
Referrer-Policy
Control how much referral information is passed when a user navigates away from your site. A strict policy (e.g., `strict-origin-when-cross-origin`) protects user privacy by ensuring sensitive query parameters or internal URLs are not leaked in the `Referer` header to external domains.
4. Authentication and Access Control
Protecting user accounts and administrative interfaces is critical.
Strong Password Policies
Enforce strong password complexity requirements (minimum length, character variety). Never store passwords in plain text. Always hash and salt passwords using a robust algorithm like `bcrypt`, `Argon2`, or `scrypt`.
Rate Limiting and Brute Force Protection
Implement rate limiting on all authentication endpoints (login, password reset) to prevent automated brute-force or credential stuffing attacks. Consider implementing CAPTCHAs or temporary account lockouts after multiple failed login attempts.
Protect Administrative Interfaces
Never expose your admin panel (e.g., `/wp-admin` or `/admin`) on the public internet without additional layers of security. Change default login URLs, enforce Multi-Factor Authentication (MFA/2FA) for all administrative accounts, and consider restricting access to specific, trusted IP addresses using a firewall or WAF.