What does a website security check look for?

A thorough website security check examines seven key areas. Each one addresses a different category of risk, from encryption and browser instructions to compliance and vulnerability testing. Here's what gets checked and why each area matters.

1. Security headers

HTTP security headers are instructions your web server sends to browsers alongside your page content. They tell the browser how to handle your site safely. A security check tests for six key headers:

• Strict-Transport-Security (HSTS) — Forces all future connections to use HTTPS. Without it, browsers will attempt plain HTTP connections that can be intercepted. A properly configured HSTS header should have a max-age of at least one year.
• Content-Security-Policy (CSP) — Restricts which sources your page can load scripts, images, and styles from. This is your primary defence against cross-site scripting (XSS) attacks. Even a basic CSP that only allows scripts from your own domain is better than none.
• X-Frame-Options — Prevents your site from being embedded in iframes on other domains. This stops clickjacking attacks where your real site is hidden behind a fake interface to trick visitors into clicking things.
• X-Content-Type-Options — Set to nosniff, this prevents browsers from guessing file types. Without it, a browser might execute an uploaded file as code even if your server labelled it as an image.
• Referrer-Policy — Controls how much URL information is shared when visitors click external links from your site. Without it, full URLs including path and query parameters can leak to third parties.
• Permissions-Policy — Controls access to browser features like camera, microphone, and geolocation. Limits the damage if a script is compromised.

Most UK business websites are missing three or more of these headers. For a detailed explanation of each one, see our guide on what HTTP security headers are.

2. SSL/TLS certificate health

The check doesn't just verify that SSL is present — it validates the full certificate chain and configuration:

• Certificate validity — Is the certificate current and not expired? Expired certificates cause browser warnings that drive visitors away and indicate neglected security.
• Certificate chain — Is the full chain of trust present? A missing intermediate certificate can cause errors on some browsers even if the certificate itself is valid.
• Protocol versions — Is the server using TLS 1.2 or 1.3? Older protocols like TLS 1.0 and 1.1 have known vulnerabilities and are deprecated by major browsers.
• Cipher suites — Are the encryption algorithms modern and secure? Weak ciphers like RC4 or 3DES should be disabled.
• Domain coverage — Does the certificate cover all the domains and subdomains your site uses? A certificate that only covers www.yourdomain.co.uk but not yourdomain.co.uk creates gaps.

3. Port scanning

Every service running on your server listens on a numbered port. A security check scans the most commonly exploited ports to see what's exposed to the internet:

• Port 21 (FTP) — File transfer. Should almost never be open to the public internet. Use SFTP over SSH instead.
• Port 22 (SSH) — Remote server access. Should be restricted to specific IP addresses, not open to the world.
• Port 25 (SMTP) — Email sending. Often open by default but frequently abused for spam if not properly configured.
• Port 3306 (MySQL) / 5432 (PostgreSQL) — Database ports. These should never be publicly accessible. An exposed database is one of the fastest paths to a data breach.
• Port 8080 / 8443 — Alternative web ports, often used for admin panels and development servers. Should be firewalled.

The only ports that should be open on a typical business website are 80 (HTTP, for redirect to HTTPS) and 443 (HTTPS). Everything else should be closed or restricted. Learn more about this in our guide on how to check open ports.

4. Cookie auditing

A security check loads your website and examines every cookie that gets set, checking for two things:

• Pre-consent tracking — Are any non-essential cookies (analytics, advertising, tracking) being set before the visitor has clicked to accept? Under UK PECR and GDPR, this is a breach. The check looks at cookies set on first page load before any consent interaction.
• Cookie flags — Do session cookies and other sensitive cookies have the Secure flag (only sent over HTTPS) and HttpOnly flag (not accessible to JavaScript)? Missing flags create opportunities for session hijacking.

This is one of the most commonly failed checks. Many sites load Google Analytics, Facebook Pixel, or other tracking technologies before the consent banner appears. The ICO has issued fines for this specific issue.

5. Email authentication (SPF, DKIM, DMARC)

The check queries your domain's DNS records to verify email authentication is properly set up:

• SPF — Does a Sender Policy Framework record exist? Does it include all legitimate email senders? Does it end with -all (hard fail) or ~all (soft fail)? Soft fail provides reduced protection.
• DKIM — Is a DomainKeys Identified Mail record published? Does it use a strong enough key (2048-bit or higher)? DKIM proves emails haven't been tampered with in transit.
• DMARC — Is a DMARC policy published? Is it set to p=reject (active protection), p=quarantine (suspicious emails go to spam), or p=none (monitoring only, no protection)?

Without all three records correctly configured, scammers can send emails that appear to come from your domain. For a full explanation, see our guide on what SPF, DKIM, and DMARC are.

6. Vulnerability testing

Beyond configuration checks, a security check tests for common attack vectors:

• SQL injection — Tests whether form inputs and URL parameters can be manipulated to run database commands. This is how attackers steal entire databases of customer information.
• Cross-site scripting (XSS) — Tests whether malicious scripts can be injected into your pages that would run in other visitors' browsers. Reflected XSS and stored XSS are both checked.
• Directory enumeration — Checks whether common directories like /admin, /backup, /.git, or /.env are accessible. Exposed directories reveal your technology stack and may contain sensitive files.
• Known software vulnerabilities — If the scanner can identify your CMS version, plugin versions, or server software, it checks these against databases of known vulnerabilities.

7. DNS configuration

The check examines your domain's DNS setup for issues that could affect security:

• DNSSEC — Is your domain signed with DNSSEC, which prevents DNS spoofing attacks?
• CAA records — Is a Certificate Authority Authorisation record set, specifying which certificate authorities are allowed to issue certificates for your domain?
• MX record validation — Do your mail exchange records point to legitimate mail servers?
• Nameserver consistency — Are your nameservers consistent and properly delegated?

Each of these seven areas catches different types of problems. A website that passes all of them has a strong security posture. Most small business websites have findings in four or five areas — typically missing headers, cookie compliance issues, and email authentication gaps.

For related guides, learn what website security scanning is, see our website security checklist for small businesses, or read about HTTP security headers explained.