Website Security Checklist 2025

Certificate must be valid and not expired - check at ssllabs.com

TLS 1.0 and 1.1 have known vulnerabilities and should be disabled

All traffic must be automatically redirected to HTTPS

Intermediate certificates must be correctly configured

Use modern ciphers, disable weak ones like RC4, DES, 3DES

Protects past sessions even if private key is compromised

Set up alerts before certificate expires (30 days in advance)

No HTTP resources loaded on HTTPS pages

Improves SSL handshake performance and privacy

Forces HTTPS connections - include max-age and includeSubDomains

Prevents XSS attacks by controlling resource loading sources

Prevents clickjacking attacks by controlling iframe embedding

Prevents MIME type sniffing attacks

Legacy XSS protection - set to "1; mode=block"

Controls referrer information sent with requests (strict-origin-when-cross-origin)

Controls browser features like camera, microphone, geolocation

Prevent caching of sensitive pages (no-store for private content)

Don't reveal server software versions (Apache, nginx, etc.)

Must obtain consent before setting non-essential cookies

Must include all required information about data processing

Required for EU businesses - name, address, contact details

Required with hosting providers, analytics tools, email services

Users must be able to request their stored data

Process for users to request data deletion

Users can export their data in machine-readable format

Inform users how form data will be processed

List all external services: analytics, fonts, CDNs, etc.

Define how long different types of data are stored

Cloudflare, Sucuri, or server-based WAF to filter malicious traffic

Automated scanning at least weekly for suspicious files

WordPress, Joomla, Drupal etc. must be current versions

Inactive code can still contain vulnerabilities

Alert when core files are modified unexpectedly

Use parameterized queries and input validation

Sanitize all user input and output encoding

Protect forms and actions with unique tokens

CDN or hosting provider with DDoS mitigation

Both database and files should be backed up automatically

3 copies, 2 different media types, 1 off-site location

Different server or cloud storage, not on same server

Protect backup files with strong encryption (AES-256)

Verify backups actually work - test quarterly

Define how long backups are kept (daily, weekly, monthly)

Step-by-step procedure for complete site restoration

Maximum acceptable downtime in case of disaster

Minimum 12 characters, mixed case, numbers, special chars

TOTP, SMS, or hardware keys for admin accounts

Lock accounts after failed attempts, CAPTCHA

Don't use /admin, /wp-admin, /administrator

Users only have permissions they need

Secure session cookies, timeout, regeneration after login

Never store plain text or weak hashes (MD5, SHA1)

Remove inactive accounts, review permissions quarterly

Time-limited tokens, no security questions, email verification

Apply security patches regularly

Apache, nginx, IIS current versions

Programming language runtimes current and secure

Only required ports open (80, 443, SSH)

Disable password auth, use SSH keys, fail2ban

Directories 755, files 644, config files 600

Prevent browsing directory contents

MySQL/PostgreSQL only accessible from localhost

Block access to configuration files via web

Get alerts when site goes down (UptimeRobot, Pingdom)

Log login attempts, file changes, admin actions

Log errors to file, show generic messages to users

Look for suspicious patterns and attacks

Alert before certificates expire

Get alerts if site is flagged as malicious

Keep logs long enough for forensics (90+ days)

Steps to take when security incident occurs