Website security audit checklist for 2026

A website security audit is a structured review of what your site exposes, how it is configured and who can change it, checked against evidence rather than assumptions. It is not a penetration test, and for many marketing sites, content management systems and shops it does not need to be. The checks below follow the order we work in, and the last section says when a site needs a penetration test instead.

TLS, certificates and security headers

Start with transport, because it is quick to verify and everything else rides on it. Accept TLS 1.2 and 1.3 only: RFC 8996, published in 2021, deprecated TLS 1.0 and 1.1 and says they must not be used. Then look at how certificates are renewed. In April 2025 the CA/Browser Forum adopted Ballot SC-081, which shortens the maximum lifetime of publicly trusted TLS certificates in stages from 398 days to 47 days, with the reductions starting in March 2026 and finishing in March 2029. Manual renewal stops being workable on that schedule, so check that every hostname renews automatically and that expiry is monitored, including the forgotten ones: the old campaign microsite, the status page, the mail autodiscover record.

HTTP Strict Transport Security (HSTS) tells browsers never to connect over plain HTTP. If you want your domain on the browser preload list, the submission rules require a max-age of at least one year (31536000 seconds), the includeSubDomains and preload directives, and HTTPS on every subdomain, including internal ones. Removal from the list can take months to reach users, so inventory your subdomains before you submit.

A Content Security Policy that blocks something

Many CSPs are long allowlists of domains. Google's guidance on web.dev says allowlist policies need heavy customisation and can be bypassed by attackers, and recommends a strict policy instead: script-src with a fresh random nonce on every response, or hashes of inline scripts, plus 'strict-dynamic', with object-src 'none' and base-uri 'none'. In an audit, check two things: whether the policy is enforced at all, and whether anyone reads its violation reports. Rolling one out takes four steps:

1. 1

   Inventory what runs

   List every inline script, event handler and external script on the page. Inline handlers such as onclick will have to move into script files before a strict policy can be enforced.

2. 2

   Deploy in report-only mode

   Send the policy as Content-Security-Policy-Report-Only with a reporting endpoint, and collect violations from real traffic for at least a full business cycle.

3. 3

   Fix what breaks

   Add nonces to legitimate scripts, move inline handlers into code, and remove any script nobody can account for.

4. 4

   Enforce, and keep watching

   Switch to the enforcing header, keep the reports flowing, and treat a sudden rise in violations as a possible injection rather than noise.

CMS, plugins and the admin surface

On WordPress, Drupal, Joomla and headless platforms alike, the core is rarely where the problem is. Plugins, themes, leftover files and the admin surface usually are.

• Every plugin and theme listed with its version, its last update and whether it is still maintained; anything inactive removed, not just deactivated.
• A source of vulnerability alerts for exactly what you run, and a patch window measured in days for issues under active exploitation.
• The admin login kept off the open internet where possible, behind single sign-on, an IP restriction or an identity-aware proxy.
• Multi-factor authentication on every administrator account, and no shared logins.
• XML-RPC, unused REST endpoints and user enumeration switched off if nothing needs them.
• The web server unable to write to code directories, and the uploads directory unable to execute scripts.
• Staging and preview sites password-protected, excluded from search indexing and free of production data.
• No leftovers in the web root: database dumps, archive files, .git directories, installer scripts or diagnostic pages.

Forms, bots and payment pages

Forms and bot abuse

Login, sign-up, password reset, contact, voucher and checkout forms are where automated abuse lands: credential stuffing, fake account creation, card testing, spam relaying and SMS pumping. Check for rate limits per address and per account, a challenge that appears when abuse is detected rather than for everyone, validation on the server rather than only in the browser, reset flows that do not reveal whether an account exists, and hard caps on the email and SMS messages a form can trigger.

Payment pages and PCI DSS v4.0.1

PCI DSS v4.0.1, published in June 2024, added no new requirements of its own, but two requirements that became mandatory on 31 March 2025 changed how payment pages are audited. In the Council's summary, requirements 6.4.3 and 11.6.1 focus on ensuring that payment page scripts are properly authorised, checked for integrity and monitored for tampering, and on managing both scripts and security-impacting HTTP headers to prevent unauthorised changes to web pages. They exist because of e-skimming: malicious code that copies card details from the browser as the customer types.

• An inventory of every script that runs on the payment page, or on the page that hosts the payment frame, each with an owner and a reason to be there.
• How each script is approved before it changes, and how its integrity is assured: Subresource Integrity hashes for static third-party files, a strict CSP, or a self-hosted copy.
• A tamper-detection mechanism that alerts on changes to scripts and security-relevant headers as browsers receive them, not only as they sit in the repository.
• Who can publish to the tag manager, and whether it may load anything on payment pages at all.

DNS, email authentication, hosting and backups

DNS

• The registrar account protected with multi-factor authentication, and a registry lock on the domains that matter most.
• CAA records naming only the certificate authorities you actually use.
• No dangling records: CNAMEs pointing at deleted cloud resources are how subdomains get taken over.
• DNSSEC enabled where your registrar and DNS host support it, and zone transfers restricted.

Email authentication

Since 1 February 2024, Google has required everyone sending to personal Gmail accounts to set up SPF or DKIM, and bulk senders, those sending more than 5,000 messages a day to Gmail accounts, to publish SPF, DKIM and a DMARC record, align the From domain, and offer one-click unsubscribe. Treat that as the floor. Audit for SPF includes left over from services you no longer use, DKIM keys of 2048 bits where your provider supports them, a plan to move DMARC from p=none to quarantine or reject once the reports are clean, and parked domains that send no mail publishing a reject policy so that nobody else can send as them.

Hosting, CDN and WAF

• The origin server unreachable except through the CDN, by IP restriction or authenticated origin pulls, so the WAF cannot be bypassed.
• WAF rules in blocking mode for the attacks you care about, not left in log-only mode since launch.
• Hosting control panels, SSH and SFTP accounts reviewed, with multi-factor authentication, and no former agencies or freelancers still holding access.
• Server software and language runtimes on supported versions, with directory listing and verbose errors switched off.

Backups

Back up files and database daily to storage outside the hosting account, under separate credentials, and keep enough history to predate a quiet compromise. The audit question that matters is not whether backups exist but how long a full restore takes; if nobody has timed one, that is the first finding.

JavaScript supply chain, privacy and consent

Every third-party script runs with the same privileges as your own code, served from infrastructure you do not control. In February 2024 the polyfill.io domain and its GitHub account were bought by a new owner; in June 2024 Sansec reported that cdn.polyfill.io was injecting malware that targeted mobile visitors on sites that embedded it, and counted more than 100,000 sites using the domain. Nothing on those sites changed; the code they trusted did.

• An inventory of every external script, its owner and the pages it loads on, with anything nobody can explain removed.
• Self-hosted copies, or Subresource Integrity hashes, for libraries that do not need to change.
• Lockfiles, dependency review and pinned versions in your build, so that a compromised package cannot ship itself.
• Monitoring that alerts when the scripts served to visitors change.

Privacy and consent

A privacy review and a security audit meet in the same place: what leaves the browser. Check which tags fire before consent and whether the banner's choices are honoured, what data reaches analytics and advertising pixels from account, checkout and health-related pages, and whether session-replay tools record form fields. Full URLs with email addresses or tokens in the query string are a common leak, and a strict Referrer-Policy only fixes part of it.

Finally, publish a security.txt file at /.well-known/security.txt, as RFC 9116 describes, with the required Contact and Expires fields, so that people who find a problem can reach you. Our responsible disclosure policy shows what sits behind one.

Fourteen checks to run before you call anyone

• TLS 1.2 and 1.3 only, with automated certificate renewal and expiry monitoring on every hostname.
• HSTS on every HTTPS response, with includeSubDomains once all subdomains support HTTPS.
• An enforced, nonce- or hash-based Content Security Policy, with violation reports that someone reads.
• nosniff, a strict Referrer-Policy, a Permissions-Policy and no-store on pages with personal data.
• A maintained inventory of CMS plugins and themes, with nothing abandoned or inactive left installed.
• Admin access behind single sign-on or an IP restriction, with multi-factor authentication for everyone.
• Rate limits, server-side validation and abuse caps on every form.
• A script inventory, change approval and tamper detection on payment pages.
• A registrar lock, CAA records and no dangling DNS records.
• SPF, DKIM and DMARC aligned, with a path to an enforcing DMARC policy.
• An origin that cannot be reached around the CDN or WAF.
• Off-site, separately credentialed backups with a timed restore.
• Tags that respect consent, and no personal data in URLs sent to third parties.
• A current security.txt file and a working disclosure contact.

When an audit is enough, and when you need a pentest

An audit checks configuration and evidence against a standard. A penetration test attacks the application to find what a configuration review cannot see: broken access control, business-logic abuse and chained vulnerabilities. Choose by what your site does, not by what it looks like.

If you are not sure which you need, a 45-minute scoping call is designed to answer exactly that, and our website security audit is built around the checks above, with evidence for every finding.