Website Security Checklist 2025: 20 Things to Check Before Launch

Website Security Checklist 2025: 20 Things to Check Before Launch

Launching a website without a security review is one of the most common and most costly mistakes teams make. Every week, new breaches make headlines because basic security measures were overlooked during development or deployment. The fixes are almost always simple. The damage from skipping them is not.

This checklist covers the 20 most important security checks you should complete before any website launch. Each item is practical, actionable, and can be verified without specialized security expertise. Work through the list systematically and you will eliminate the vulnerabilities that attackers exploit most often.

HTTPS and TLS

1. Enforce HTTPS everywhere

Every page, asset, API endpoint, and resource on your site must be served over HTTPS. Configure your server to redirect all HTTP requests to HTTPS with a 301 permanent redirect.

Verify that:

• No mixed content warnings appear in the browser console
• All internal links use HTTPS or protocol-relative URLs
• API endpoints reject HTTP connections
• Assets (images, scripts, stylesheets) are loaded over HTTPS

2. Use TLS 1.2 or 1.3 only

Disable TLS 1.0 and TLS 1.1 in your server configuration. These versions have known vulnerabilities and are no longer supported by modern browsers.

Configure strong cipher suites that use ECDHE key exchange and AEAD encryption (AES-GCM or ChaCha20-Poly1305). Remove all CBC-mode, DES, 3DES, and RC4 ciphers.

Security Headers

3. Set Content-Security-Policy

Define a strict CSP that limits which sources can serve scripts, styles, images, and other resources. Start with default-src 'self' and add exceptions only as needed.

Use Content-Security-Policy-Report-Only during development to identify what would break before enforcing the policy in production.

4. Enable HSTS with preload

Add the Strict-Transport-Security header with a max-age of at least one year, includeSubDomains, and preload. This prevents SSL stripping attacks and signals browsers to always use HTTPS.

5. Set X-Content-Type-Options, X-Frame-Options, and Referrer-Policy

These three headers take seconds to add and block entire classes of attacks:

• X-Content-Type-Options: nosniff — prevents MIME-type sniffing
• X-Frame-Options: DENY — prevents clickjacking
• Referrer-Policy: strict-origin-when-cross-origin — prevents referrer information leakage

Cookie Security

6. Secure all cookies

Every cookie set by your application should have these flags:

• Secure — only send over HTTPS
• HttpOnly — prevent JavaScript access (for session cookies)
• SameSite=Lax or SameSite=Strict — prevent cross-site request forgery

Review third-party cookies as well. Remove any that are not essential.

CSRF Protection

7. Implement CSRF tokens on all state-changing operations

Every form submission and API call that modifies data must include a CSRF token. Modern frameworks (Django, Rails, Next.js, Laravel) have built-in CSRF protection, but you must verify it is actually enabled and not accidentally disabled.

Test by:

• Submitting forms without the CSRF token (should fail)
• Replaying requests with old tokens (should fail)
• Verifying tokens are tied to user sessions

Input Validation

8. Validate all input server-side

Never rely solely on client-side validation. Every input from users, APIs, and external systems must be validated on the server:

• Check data types, lengths, and ranges
• Reject unexpected fields
• Normalize Unicode and encoding before processing
• Use allowlists rather than blocklists when possible

SQL Injection Prevention

9. Use parameterized queries everywhere

Never concatenate user input into SQL queries. Use parameterized queries or prepared statements for every database interaction.

Review your ORM queries as well. Some ORM methods allow raw SQL injection if used incorrectly. Search your codebase for any raw query methods and verify they use parameter binding.

XSS Prevention

10. Encode all output

Every piece of user-generated content displayed in your application must be properly encoded for its context:

• HTML context: HTML-encode special characters
• JavaScript context: JavaScript-encode
• URL context: URL-encode
• CSS context: CSS-encode

Use your framework''s built-in template escaping. Never insert raw user input into HTML with methods like innerHTML or dangerouslySetInnerHTML without sanitization.

Authentication Security

11. Enforce strong passwords and MFA

Require passwords of at least 12 characters. Implement rate limiting on login attempts. Support multi-factor authentication (MFA) and strongly encourage or require it for admin accounts.

12. Secure session management

• Generate cryptographically random session IDs
• Regenerate session IDs after login
• Set appropriate session timeouts (15-30 minutes for sensitive applications)
• Invalidate sessions properly on logout
• Store sessions server-side, not in JWTs with long expiry

File Upload Security

13. Validate and sandbox file uploads

If your application accepts file uploads:

• Validate file types by content (magic bytes), not just extension
• Limit file sizes
• Rename uploaded files to prevent path traversal
• Store uploads outside the web root or in a separate storage service
• Scan uploads for malware if possible
• Never execute uploaded files

Error Handling

14. Use generic error messages in production

Stack traces, database errors, and internal paths must never be exposed to users. Configure your application to:

• Show friendly, generic error messages to users
• Log detailed errors server-side only
• Return consistent error response formats from APIs
• Never include sensitive data in error messages

Logging and Monitoring

15. Implement security-relevant logging

Log these events at minimum:

• Authentication attempts (successful and failed)
• Authorization failures
• Input validation failures
• Administrative actions
• Account changes (password reset, email change)

Ensure logs do not contain sensitive data (passwords, tokens, credit card numbers). Send logs to a centralized system and set up retention policies.

16. Set up monitoring and alerting

Configure alerts for:

• Multiple failed login attempts from the same IP
• Unusual traffic patterns or spikes
• Error rate increases
• New admin account creation
• Certificate expiration warnings

Dependency Management

17. Audit and update dependencies

Run dependency vulnerability scans before launch:

• npm audit for Node.js projects
• pip audit or safety check for Python projects
• Use Dependabot or Renovate for automated update PRs

Remove unused dependencies. Pin dependency versions. Review changelogs before updating.

Backup Strategy

18. Verify backup and restore procedures

Before launch, confirm that:

• Automated backups are running on schedule
• Backups are stored in a separate location (different region or provider)
• Backups are encrypted at rest
• You have tested a full restore from backup
• Restore time meets your recovery time objective

DNS Security

19. Configure DNSSEC and CAA records

DNSSEC prevents DNS spoofing attacks by cryptographically signing DNS records. Enable it through your DNS provider.

CAA records specify which certificate authorities are allowed to issue certificates for your domain. This prevents unauthorized certificate issuance.

yourdomain.com. CAA 0 issue "letsencrypt.org"
yourdomain.com. CAA 0 iodef "mailto:security@yourdomain.com"

Also configure email security records:

• SPF — specifies which servers can send email for your domain
• DKIM — signs outgoing emails to prevent spoofing
• DMARC — defines how to handle emails that fail SPF/DKIM checks

Rate Limiting and Incident Response

20. Implement rate limiting and prepare an incident response plan

Rate limiting prevents brute force attacks, credential stuffing, and API abuse. Apply rate limits to:

• Login endpoints (strict: 5-10 attempts per minute)
• API endpoints (based on your expected traffic)
• Password reset and account creation
• Contact forms and public submissions

Incident response plan — document a simple playbook before you need it:

1. 1Who declares an incident
2. 2How to contain the breach (kill switches, IP blocking)
3. 3Who communicates internally and externally
4. 4How to preserve evidence for investigation
5. 5Post-incident review process

Automate Your Security Checks with ZeriFlow

Going through this checklist manually for every launch is time-consuming and error-prone. ZeriFlow''s free scan automates the verification of most items on this list, including:

• HTTPS and TLS configuration
• Security headers (CSP, HSTS, X-Frame-Options, and more)
• Cookie security flags
• DNS security (DNSSEC, CAA, SPF, DKIM, DMARC)
• Information disclosure
• SSL certificate validation

Run a scan before every launch, after every major deployment, and on a regular schedule to catch configuration drift.

For teams that need continuous monitoring, ZeriFlow Pro provides unlimited quick scans and advanced scanning with detailed expert-level recommendations.

Your Pre-Launch Action Plan

1. 1Print this checklist or save it as a team reference
2. 2Assign each item to a team member
3. 3Run a ZeriFlow scan to get your baseline score
4. 4Fix the critical items first (HTTPS, headers, input validation, authentication)
5. 5Address the remaining items before launch
6. 6Schedule regular re-scans to maintain your security posture
7. 7Review and update this checklist quarterly as new threats emerge

Security is not a one-time task. It is an ongoing practice. But getting the fundamentals right before launch prevents the vast majority of common attacks and gives your team a solid foundation to build on.