Website Security Checklist 2026: 40 High-Impact Checks

Most teams do not lose security because of one advanced zero-day. They lose because of basic gaps that stayed open too long: exposed .env files, weak headers, old plugins, over-permissive CORS, and forgotten admin paths. This checklist is designed for fast execution and measurable risk reduction.

Why this checklist matters

A checklist gives security teams and engineering leaders a shared operating model. It turns abstract risk into concrete tasks, clear ownership, and repeatable review cycles.

Critical checks (do first)

• Secrets exposure: verify .env, .git, backup archives, and debug artifacts are inaccessible.
• Authentication hardening: enforce MFA on admin accounts and block weak password policies.
• Patch urgency: identify outdated CMS/plugins/libraries with known CVEs.
• TLS posture: valid certificate chain, modern protocols/ciphers, no mixed content.
• Admin/API exposure: close or restrict unnecessary endpoints by IP or identity.

Core platform checks

Application layer

• Input validation for all user-controlled fields.
• Output encoding to mitigate reflected/stored XSS.
• CSRF protections for state-changing routes.
• Rate limiting on auth, password reset, and API endpoints.

HTTP and browser controls

• Content-Security-Policy defined and maintained.
• Strict-Transport-Security enabled with suitable max-age.
• X-Frame-Options, X-Content-Type-Options, and Referrer-Policy present.
• Cookie flags: Secure, HttpOnly, SameSite.

Infrastructure and cloud

• Only necessary ports are exposed publicly.
• Storage buckets are private by default.
• DNS records (SPF, DKIM, DMARC, CAA) are valid and intentional.
• WAF and firewall rules reviewed after each major release.

Operational checks

• Logging: centralize security events and auth anomalies.
• Alerting: set alert thresholds for failed auth spikes and endpoint abuse.
• Backups: encrypt, test restore, and isolate immutable copies.
• Incident playbook: define owner, triage SLAs, and communication flow.

# Minimal recurring workflow (weekly)
1) Run external scan on production domain
2) Triage critical/high findings
3) Assign remediation owner + deadline
4) Re-scan and verify closure
5) Export report for stakeholders

Recommended scan cadence

For most production systems, run a quick external scan weekly and after every deploy. Run a deeper control review monthly and before major launches, audits, or vendor reviews.

Specialist checklists by platform

• WordPress security checklist 2026 — plugin risk, wp-config, and admin hardening
• React & Next.js security checklist — env leaks, source maps, API routes
• Shopify security hardening checklist — app permissions, checkout scripts
• Laravel production security checklist — .env, debug, queue safety
• Pre-launch security checklist — go-live gate controls

The full 40-point checklist

This expanded checklist covers all major control areas for production web applications. Use it as a quarterly audit template or a pre-release gate.

Secrets and sensitive file exposure

1. Verify .env and all environment files return 403 or 404 — never their contents.
2. Confirm .git/ directory is not web-accessible (returns 403, not a directory listing or repository contents).
3. Verify database backup files (.sql, .dump, .bak) are not web-accessible.
4. Confirm phpinfo(), info.php, and debug endpoints are removed from production.
5. Verify source maps (.js.map) are disabled or restricted in production.

SSL/TLS and certificate hygiene

6. Valid, unexpired certificate with full chain (no missing intermediate certificates).
7. TLS 1.0 and 1.1 disabled; TLS 1.2+ only.
8. HSTS header present with max-age of at least 6 months and includeSubDomains.
9. No mixed content — all resources loaded over HTTPS.
10. HTTP automatically redirects to HTTPS (301, not 302).

Security headers

11. Content-Security-Policy defined — no unsafe-inline or unsafe-eval without compensating controls.
12. X-Frame-Options: SAMEORIGIN or CSP frame-ancestors set to prevent clickjacking.
13. X-Content-Type-Options: nosniff present on all responses.
14. Referrer-Policy set to strict-origin-when-cross-origin or stricter.
15. Permissions-Policy disables unnecessary browser features (camera, microphone, geolocation).

Authentication and access control

16. MFA enforced for all admin and privileged accounts.
17. Login endpoint has rate limiting (maximum 5-10 attempts per minute per IP).
18. Password reset and OTP endpoints have separate rate limits.
19. Session cookies have Secure, HttpOnly, and SameSite=Strict flags.
20. Session tokens are invalidated on logout (server-side session destruction, not just client-side cookie deletion).

Input validation and output encoding

21. All database queries use parameterized statements — no string concatenation with user input.
22. User-supplied HTML is sanitized with a library (DOMPurify, HTMLPurifier) before rendering.
23. File upload validation enforces MIME type, file size, and extension — files stored outside web root.
24. API endpoints validate and reject unexpected fields — no mass assignment vulnerabilities.
25. Error messages do not reveal stack traces, SQL queries, or internal paths in production.

CORS and API configuration

26. Access-Control-Allow-Origin is an explicit allowlist — never * with credentials.
27. API authentication is required on all non-public endpoints.
28. API rate limiting is applied at the endpoint level, not just globally.
29. Internal APIs and admin routes are not exposed to the public internet.
30. API keys and service credentials are not present in client-side JavaScript bundles.

Infrastructure and cloud

31. Only ports 80 and 443 are open publicly — all others blocked at firewall/security group.
32. Database ports (3306, 5432, 6379, 27017) accept connections from application subnet only.
33. Cloud storage buckets (S3, GCS, Azure Blob) are private by default — no public read access.
34. SSH access restricted to key-based authentication; password auth disabled.
35. DNS CAA records published to restrict which CAs can issue certificates for your domain.

Email authentication

36. SPF record published and within the 10 DNS lookup limit.
37. DKIM configured with a 2048-bit key and valid selector.
38. DMARC record published with at minimum p=quarantine (ideally p=reject).

Monitoring and incident readiness

39. Centralized logging captures authentication failures, privilege changes, and 4xx/5xx spikes.
40. Incident response plan exists with defined severity levels, owners, and first-60-minutes checklist.

Related fix guides

• Security headers guide: CSP, HSTS, X-Frame-Options
• How to prevent SQL injection attacks
• How to prevent XSS
• How to set up SPF, DKIM & DMARC
• How to fix CORS misconfiguration

Frequently Asked Questions

How often should we run a website security checklist?

Run it after each major deployment, weekly for baseline hygiene, and monthly for a full control review.

What should small teams prioritize first?

Secrets exposure, authentication hardening, patching vulnerable software, and reducing unnecessary attack surface.

Is an automated scan enough?

Automation covers most technical hygiene. Keep periodic manual review for business logic and access design risks.