Website Security Audit: What to Check and How to Score It

Use a practical website security checklist for HTTPS, headers, email and certificates, with recommended settings, staged fixes and honest scoring limits.

Overview

Start a website security audit with a practical baseline: working HTTPS, permanent HTTP redirects, browser security headers, authenticated business email and automated certificate renewal. Assign each change to the hosting, application, DNS or email owner. A public configuration review identifies delivered settings; account access, backups and incident readiness require internal evidence. Give the IT team a dated list of observed gaps, recommended settings and validation steps so they can act without treating a public result as a complete assessment.

For an IT generalist, the most useful first output is a short, dated work list. Each item should identify what was observed, which system it concerns, who should review it and what evidence would show improvement. Separate direct observations from inference. A response header is direct evidence of what one response advertised; its presence does not prove that the application resists every relevant attack.

Four areas to review first

Use TLS 1.2 as the minimum and prefer TLS 1.3, following the baseline in NIST SP 800-52 Rev. 2. Redirect HTTP to HTTPS on the same host with 301 or 308 before enabling HSTS. Start HSTS with a short lifetime and ramp to one year, max-age=31536000, after checking clients. Ensure certificates cover example.com and www.example.com, including redirecting names. Add includeSubDomains only after subordinate services work over HTTPS; preload needs separate approval because browser-list removal is slow.

Set X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin. Use CSP frame-ancestors 'none' for pages that must not be embedded, or 'self' for same-origin embedding; DENY or SAMEORIGIN are the corresponding legacy X-Frame-Options choices. Trial a starter CSP as Content-Security-Policy-Report-Only, resolve compatibility issues, then enforce it. Use Secure, HttpOnly and SameSite=Lax or Strict for session cookies, testing login flows first. Hide unnecessary server version strings, while continuing to patch the underlying software.

Publish one SPF policy containing approved senders and ending in ~all during transition or -all after validation, never +all. Stay within the 10 DNS-querying mechanism and modifier limit, including nested evaluation. Enable DKIM with at least 2048-bit RSA keys where supported and rotate through your provider. Publish DMARC with p=none and rua reporting, reconcile legitimate senders, then progress to quarantine and reject. Google and Yahoo bulk-sender rules have required SPF, DKIM and at least monitoring DMARC since February 2024; review each receiver’s volume definition.

Automate certificate renewal and monitor served expiry as public certificate lifetimes shorten. Confirm the deployment step replaces certificates on every intended edge. Publish CAA for your actual issuer and an iodef role contact after checking managed-platform requirements. For example, authorize letsencrypt.org only if your certificate service uses it. Trial issuance or renewal before narrowing the issuer list; CAA changes can block legitimate renewal. Maintain registrar and DNS ownership with a named backup, since public records cannot establish account recovery readiness.

How to interpret a best-practice score

Meo calculates the share of observed best practices in place: aligned checks divided by checks that produced an observation. For example, 12 aligned checks among 16 observed checks produce 75%. This is an arithmetic illustration, not a claim about a real company. Unknown evidence never becomes a pass or a fail. Checks marked not applicable are excluded from the applicable denominator.

Coverage belongs beside the percentage. A small set of visible controls can look strong while important questions remain unanswered. An area receives a letter grade only when at least half its applicable scorable checks were observed. The overall percentage requires at least six observed checks and at least two graded areas. These gates prevent a result based on very little evidence from looking complete.

Do not interpret the percentage as a probability of breach, a compliance verdict or a comparative rating of businesses. Correlated checks can share a single root cause, such as an incorrect edge configuration. Fix priority should consider the role of the affected service, the quality of evidence, the cost of disruption and the owner’s ability to validate the change.

What to check

Begin with a domain and service inventory that your team recognizes. Confirm the apex, www host, hosting provider, DNS administrator, mail platform and certificate renewal owner. Keep a separate list of third-party systems and internal services because the instant public review does not reach them. Record the date and exact scope of each observation so that a later reviewer can reproduce the intended check.

Use the examples below as concrete targets, adapting only the service-specific values. For example.com, first make HTTPS work and redirect HTTP to it; ramp HSTS from 300 seconds through a day and a week to one year. For mail, inventory providers before replacing the single SPF policy or advancing DMARC. The documentation IP shown is not a real sending service. The reporting mailbox must exist and have an owner before reports can be useful.

For each proposed fix, specify an owner and a validation step. The hosting administrator can verify redirects and renewal; the application owner can trial a Content Security Policy; the email administrator can reconcile senders before enforcing DMARC. Retest the relevant entry points after changes. Keep unknown items open until the responsible owner supplies reliable evidence, rather than closing them to improve a percentage.

HTTP upgrade for http://example.com/:
HTTP/1.1 308 Permanent Redirect
Location: https://example.com/

HTTPS response after the HSTS ramp:
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

SPF syntax example; replace the documentation IP with approved senders:
example.com. TXT "v=spf1 ip4:192.0.2.10 -all"

Initial DMARC monitoring record:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Common mistakes: turning observations into guarantees

A long list of absent headers is not automatically a list of exploitable weaknesses. Some headers apply only to particular response types, and browser defaults affect behavior. Conversely, a header can be present with permissive settings. Ask what the configuration accomplishes and whether it applies to the actual application response, including errors and authenticated routes reviewed under separate authorization.

Do not silently combine evidence collected at different times or across unrelated hosts. An old certificate-transparency record and a current page response answer different questions. Avoid reporting a service outage from a timeout, or a missing control from an access challenge. Distinguish collection failure from an observed setting that needs attention, and preserve that distinction when passing the work list to a manager.

How the free Meo audit checks this

The instant audit uses public DNS and standard TLS, starting with HTTPS and HTTP apex root requests. It reaches exact www through an in-scope redirect or an HTTPS fallback if no apex HTTPS page was accepted and budget remains; it does not always sample both hosts. It has 21 planned checks, of which 16 can contribute to the four scored areas. Mail routing, public DNS destination validation and technology families provide context; public reputation and indexed exposure do not contribute to the score.

The collection limit is five page requests including redirects, with a 90-second deadline. It does not execute scripts, fetch linked assets, enumerate subdomains or guess DKIM selectors. SPF include chains, real-message alignment, complete CAA semantics and browser enforcement are not validated. Sources that are blocked or unavailable remain unknown. The result is a starting point for an IT conversation and an agreed expanded review.

Frequently asked questions

Is a public website check a full cybersecurity assessment?

No. A full assessment may require interviews, account and asset inventories, configuration records and separately authorized testing. Public observations cover a much smaller surface and should be described with that scope.

Can I compare two companies using their percentages?

Compare the actual checks and coverage first. Different unknowns and application requirements can make percentages misleading. The observed best-practice score is intended to organize a review, not rank organizations.

Does a timeout mean the website failed?

A timeout establishes that the collector did not complete that observation within its limits. It does not establish a failed security control, an outage for ordinary visitors or a compromise.

Who should receive the remediation list?

Start with the IT owner who can coordinate hosting, application and mail administrators. Give them observation dates and limitations as well as suggested changes, so they can verify context and assign responsibility.

What comes after the instant audit?

Review the supported items, resolve unknowns with system owners and decide whether a broader public review is useful. Internal assessment or active testing needs its own written scope and evidence-handling agreement.

Sources and review dates

Content reviewed against the instant audit’s implemented checks and the references below. This is a content review date, not a new revision date for these standards. Confirm provider-specific settings with the responsible administrator before deployment.

Read the complete scoring method and collection limits.

Related guides

Start with your domain

Get the free instant audit before deciding whether an expanded review would help.