Scan your site free
Web Security

Website security checklist: 7 things to check before you go live

April 28, 2026  ·  5 min read  ·  By masoSec

Most website security problems aren't discovered during development. They're discovered after launch — either by a security researcher who reports it, or by an attacker who doesn't.

The good news is that the most common issues are easy to check for. You don't need a security specialist or a penetration test to catch the basics. Here are 7 things every business website should verify.

1

HTTPS is enabled and the certificate is valid

Your site should load over HTTPS on all pages, including every subpage and API endpoint. The SSL certificate should be valid (not expired), issued by a trusted authority, and cover your domain correctly. A certificate that expired last week is just as insecure as no certificate. Check your expiry date — many certificates are only valid for 90 days and need to be renewed automatically.

2

Security headers are set

HTTP security headers are instructions your server sends to the browser about how to handle your content. Without them, browsers are left to guess — and attackers can take advantage of that. The key headers to set: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Strict-Transport-Security. Missing headers are one of the most common — and most easily fixed — findings in security audits.

3

No sensitive files are publicly accessible

Configuration files, backup files, and development artifacts are frequently left accessible on production servers by accident. A publicly accessible .env file exposing your database password or API keys is a serious breach waiting to happen. Common paths to check: /.env, /wp-config.php, /.git/config, /backup.zip, /phpinfo.php. None of these should return a 200 response on a production server.

4

Your CMS or framework is up to date

Outdated software is the single most common entry point for attackers. WordPress core, plugins, and themes all have known vulnerabilities that are publicly listed in databases. Running a plugin version from 2 years ago isn't just bad practice — it's an open invitation. If you're using a CMS, set up automatic updates for security releases, and audit your plugins list for anything that hasn't been maintained.

5

DMARC, SPF, and DKIM are configured for your email

Without these records, anyone can send emails that appear to come from your domain. Your clients could receive phishing emails that look like they're from you — and your email provider can't stop it. DMARC (combined with SPF and DKIM) closes this gap. Check your DNS records for v=DMARC1, v=spf1, and your DKIM selector.

6

No default credentials are in use

If your site uses an admin panel, database, or any third-party tool, make sure default usernames and passwords have been changed. "admin/admin", "root/root", and "admin/password" are tried automatically by every automated scanner on the internet. This includes phpMyAdmin, WordPress admin, Grafana, and any control panel software.

7

Subdomain takeover isn't possible

If you've ever set up a subdomain that pointed to an external service (Heroku, GitHub Pages, AWS, Netlify) and then stopped using that service, the subdomain may still be pointing to an unclaimed slot. An attacker can claim that slot and serve content from your subdomain — including phishing pages or malware. Audit your DNS records and remove CNAME entries for services you're no longer using.

Most of these checks can be automated. You shouldn't have to remember to do them manually every month — a monitoring tool can check continuously and alert you when something changes.

How often should you check?

The answer is: continuously. SSL certificates expire. Plugins get new CVEs. A developer accidentally commits a config file. Security isn't a one-time audit — it's an ongoing state. Monthly automated checks at minimum; weekly if your site handles sensitive data or payments.

What happens when something fails?

The severity varies enormously. A missing X-Frame-Options header is a relatively minor issue. An exposed .env file with database credentials is a critical incident. Prioritise fixes by impact: anything exposing credentials or allowing account takeover should be fixed immediately. Security header gaps can be fixed in the next deployment cycle.

Run a free security scan on your website

masoSec checks SSL, headers, exposed files, email security, CMS vulnerabilities, and more — in under a minute.

Scan your site free