Security checklist for corporate websites (15 points)

There's an important difference between "my site has never been attacked" and "my site is secure." The first is luck, or nobody having looked closely. The second requires active review. This checklist gathers the points that show up most often in real institutional-website security scans — it's not theory, it's what usually turns out to be missing in practice.

I've organized it by priority: what to fix first, what comes after.

High priority

1. HTTPS across the entire site, no exceptions Not just the login or contact page — everywhere. And HTTP should redirect to HTTPS automatically, never serve plain-text content.

2. Valid SSL/TLS certificate, renewing automatically An expired certificate is the fastest way to lose visitor trust (and to drop in Google rankings, which penalizes this). Prefer automatic renewal over a manual calendar reminder.

3. Content-Security-Policy (CSP) We cover this in detail in another article — it's the main defense against XSS.

4. No secrets exposed publicly An .env file, an API key, a database credential accessible via a direct URL. It sounds obvious, but it's one of the most common findings in scans — usually from a misconfigured deploy, not a conscious decision.

Medium priority

5. HSTS (Strict-Transport-Security) with includeSubDomains Ensures the browser never tries to load the site over HTTP again, not even on subdomains.

6. X-Frame-Options or frame-ancestors Prevents the site from being embedded in an invisible iframe on another page (clickjacking).

7. X-Content-Type-Options: nosniff Prevents the browser from trying to "guess" a file's type and executing something dangerous disguised as an image or document.

8. DMARC, SPF, and DKIM configured in DNS Without this, anyone can send email impersonating your domain. It's worth starting in monitoring mode (p=none) and gradually evolving to enforcement (p=reject).

9. CAA record in DNS Defines which certificate authorities are allowed to issue a certificate for your domain — without it, any CA can issue one, including by mistake or fraud.

10. Cookies with the right attributes Secure, HttpOnly, and SameSite properly configured prevent session cookies from being stolen or used in cross-site attacks.

Lower priority (but still worth it)

11. Permissions-Policy Restricts which browser APIs (camera, microphone, geolocation) the site and third-party scripts can use — even if you use none of them, it's worth blocking explicitly.

12. Referrer-Policy Controls how much information about the originating URL leaks to external sites when someone clicks an outbound link.

13. security.txt A simple file at /.well-known/security.txt with a contact for reporting vulnerabilities. Low cost, signals that someone is actually paying attention on the other end.

14. DNSSEC Protects against DNS cache poisoning. Depends on your DNS provider's support — worth confirming before trying to enable it.

15. No unnecessary technology exposure An X-Powered-By header, exact framework versions in the HTML, deploy configuration files publicly accessible — none of these is a vulnerability by itself, but each makes it easier for someone mapping out targets.

How to use this checklist

You can't review all of this from memory, and you can't rely on a feeling of "I think it's all fine." The fastest path is running an automated scan that confirms each item with real evidence — what's present, what's missing, and what needs more context (like an authenticated pentest) to confirm.

After the first round of fixes, it's worth knowing how to read the resulting report without getting lost in the sheer number of items.