Website Security Audit: The Complete 2026 Guide
What a website security audit actually checks, the four levels of depth available, and an eight step process you can run this week.
Run the same check right now — free
Enter your domain and get a 9-point audit — DNS, SPF/DKIM/DMARC, SSL, security headers, dark-web exposure — in 60 seconds.
No signup · <60s · GDPR/EU processing
A website security audit is a structured review of everything an attacker can see and reach from outside your organisation: your TLS certificate and cipher configuration, your DNS records, your email authentication (SPF, DKIM and DMARC), your HTTP security headers, the software versions you leak in responses, and any company credentials already circulating on the dark web. A good audit ends with a ranked list of findings, each with an owner and a concrete fix. The externally visible layer takes about sixty seconds to scan automatically. The full exercise, done properly, takes an afternoon.
This guide covers what an audit actually tests, the four levels of depth available to you, an eight step process you can run this week, and how often to repeat it.
Why the 2026 threat picture changed the maths
Verizon's 2026 Data Breach Investigations Report, published on 19 May 2026 and built on more than 31,000 security incidents and over 22,000 confirmed breaches across 145 countries, found that exploitation of vulnerabilities was the initial access vector in 31% of breaches. That is the first time in the report's nineteen editions that it has overtaken stolen credentials, which fell to 13%.
Two supporting figures from the same report explain why infrequent auditing is now expensive. Only 26% of the critical vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalogue were fully remediated during 2025, down from 38% the year before. And the median time to fully remediate a vulnerability rose to 43 days. Attackers are moving faster while defenders are moving slower, so the gap you leave between audits is the gap they work in.
The certificate side changed too. Under CA/Browser Forum ballot SC-081v3, approved in April 2025 by a vote of 29 to 0, the maximum lifetime of a publicly trusted TLS certificate dropped from 398 days to 200 days on 15 March 2026. It falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Domain validation reuse periods shrink on the same dates. Any renewal process that still relies on a person remembering a calendar entry will fail within this cycle, which makes certificate expiry a permanent audit item rather than an annual one.
What a website security audit actually checks
| Layer | What the audit looks for | Usual owner | Sensible cadence |
|---|---|---|---|
| TLS and certificates | Expiry date, chain completeness, hostname match, protocol versions, weak ciphers | Ops or hosting provider | Continuous monitoring, review monthly |
| DNS | Dangling CNAME records, missing DNSSEC, open zone transfers, stale subdomains | DNS or platform team | Quarterly, plus after every migration |
| Email authentication | SPF record validity and lookup budget, DKIM selectors, DMARC policy and reporting | IT or email admin | Quarterly, plus after any provider change |
| HTTP security headers | HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy | Web or platform team | After every deployment |
| Application surface | Outdated CMS, plugins and libraries, exposed admin paths, verbose error pages | Development team | Monthly, automated |
| Data exposure | Company email addresses and credentials in known breach corpora | Security or IT lead | Continuous monitoring |
| Performance and availability | Core Web Vitals, uptime, response times under load | Web team | Weekly |
The first four rows are the ones an external scanner can assess without any access to your systems, which is why they are the fastest place to start and usually where the first real findings appear.
What audits find missing most often
The HTTP Archive's Web Almanac 2025, which analyses millions of real websites, measured how many sites actually set each protective HTTP header. The answer is sobering: the single most widely adopted security header is present on roughly half of sites, and Content Security Policy on barely a fifth.
Adoption of key HTTP security headers on mobile pages. Source: HTTP Archive Web Almanac 2025, Security chapter. Figures for X-Content-Type-Options and X-Frame-Options are approximate as published.
Strict-Transport-Security reached 36% of pages in 2025, up six percentage points on 2024 and the strongest riser of the year. Content Security Policy grew from 18.5% to 21.9%. Newer controls such as Permissions-Policy and Cross-Origin-Opener-Policy remain below 10%. Even among sites that do deploy CSP, 92% still allow unsafe-inline in script-src and 77% allow unsafe-eval, which removes most of the protection the header is meant to provide. Adopting a header is not the same as configuring it well, and a real audit checks the value, not just the presence.
Transport encryption is in far better shape. TLS 1.3 now carries roughly 76% of page loads, TLS 1.2 is down to 13 to 15%, and HTTPS adoption exceeds 95% in every country the Almanac measures except Japan. If your audit still finds TLS 1.0 or 1.1 enabled, you are in a small and conspicuous minority.
Email authentication remains the widest gap of all. DMARCguard's State of Email Authentication 2026, a scan of 5,499,028 Tranco-ranked domains completed on 27 February 2026, found SPF on 56.0% of domains, DMARC on 30.4% and DKIM on just 22.7%.
The four levels of audit, and when each is worth it
| Audit type | Typical duration | What it finds | What it misses | Good for |
|---|---|---|---|---|
| Automated external scan | Under 2 minutes | Certificate, DNS, email auth, header and exposure issues visible from outside | Business logic flaws, authenticated areas | Continuous baseline, every site, every month |
| Authenticated vulnerability assessment | 1 to 5 days | Known CVEs in your stack, misconfigured services, weak access controls | Novel logic abuse, chained exploits | Regulated or transactional sites, annually |
| Penetration test | 1 to 3 weeks | Chained and creative attacks, privilege escalation, real exploitability | Anything outside the agreed scope or time box | Before a major launch, or annually for high-risk systems |
| Manual code and architecture review | 1 to 4 weeks | Design flaws, insecure defaults, supply chain risk in dependencies | Runtime and infrastructure issues | New products, or after an incident |
Most organisations should treat the first row as always on and choose one of the other three per year based on risk. Running a penetration test on a site that still fails an automated scan wastes the test, because the tester spends the engagement reporting findings a free tool would have caught in a minute.
How to run a website security audit in eight steps
- Inventory what you own. List every domain, subdomain and third-party service that renders under your brand. Audits fail most often because the vulnerable host was one nobody remembered owning.
- Run an external scan first. Get the outside-in picture before you spend anyone's time. This tells you which of the seven layers above are already failing.
- Verify certificates and renewal automation. Check expiry, chain and hostname coverage, then check that renewal is automated. Under the 200 day limit now in force, manual renewal is a scheduled outage.
- Check DNS for orphans. Every CNAME pointing at a service you no longer use is a subdomain takeover waiting to happen. Remove stale records rather than leaving them.
- Validate email authentication end to end. Confirm your SPF record stays within its ten DNS lookup budget, that DKIM signs all sending sources, and that DMARC has a policy stronger than
p=nonewith a working reporting address. - Review header values, not just header presence. A CSP full of
unsafe-inlineand an HSTSmax-ageof 300 seconds both pass a naive checklist and protect nobody. - Patch by exploitability, not by CVSS score alone. Anything on the CISA Known Exploited Vulnerabilities catalogue that touches your stack goes first.
- Write the findings down with an owner and a date. An audit that ends in a conversation instead of a ticket has not happened.
Mapping your findings to OWASP Top 10:2025
OWASP published the 2025 edition of its Top 10 in January 2026, after announcing it at Global AppSec in Washington DC in November 2025. Two categories are new, and both are relevant to what an audit should now cover.
| Rank | Category | Change from 2021 | Visible in an external audit? |
|---|---|---|---|
| A01 | Broken Access Control | Stable at the top for four editions, now absorbs SSRF | Partly |
| A02 | Security Misconfiguration | Up from A05 | Yes |
| A03 | Software Supply Chain Failures | New, expands the old A06 | Partly |
| A04 | Cryptographic Failures | Down from A02 | Yes |
| A05 | Injection | Down from A03 | Partly |
| A06 | Insecure Design | Down from A04 | No |
| A07 | Authentication Failures | Stable | Partly |
| A08 | Software and Data Integrity Failures | Stable | Partly |
| A09 | Security Logging and Alerting Failures | Renamed from Monitoring | No |
| A10 | Mishandling of Exceptional Conditions | New, replaces SSRF as a standalone entry | Partly |
The promotion of Security Misconfiguration to second place is the single most useful signal here for anyone planning an audit. It is the category most fully addressed by external scanning, and the category most often left to whoever set the server up years ago.
How often should you audit?
Continuously for anything automatable, quarterly for anything requiring judgement, and immediately after any of these events: a platform or hosting migration, a change of email provider, a new subdomain going live, a dependency major version bump, or a staff departure with administrative access. The Verizon figure that third parties now feature in 48% of breaches, a 60% increase year on year, means a supplier change deserves the same treatment as a change of your own.
Frequently asked questions
How long does a website security audit take? An automated external scan of certificates, DNS, email authentication, headers and exposure completes in about a minute. A thorough internal review of the findings, with fixes assigned, typically takes half a day for a small site.
Do I need a penetration test, or is a scan enough? A scan is the right and sufficient starting point for every site, and the only sensible thing to run continuously. A penetration test adds value once your automated findings are clean and you have authenticated functionality, payments or personal data worth attacking.
Can an audit be done without access to my server? Most of the highest-value checks can. TLS configuration, certificate validity, DNS hygiene, SPF, DKIM, DMARC, security headers and dark web exposure are all assessable from the public internet. Code review and authenticated testing are the parts that need access.
What is the first thing to fix after an audit?
Anything on the CISA Known Exploited Vulnerabilities catalogue, then an expiring or misconfigured certificate, then a DMARC policy of p=none. These three account for a disproportionate share of real-world compromise relative to the effort of fixing them.
Start with the sixty second version
You cannot fix what you have not measured, and the outside-in layer of a website security audit is free to measure. FortifyNet's scanner checks your SSL and TLS configuration, DNS records, SPF, DKIM and DMARC, HTTP security headers, dark web exposure and performance in about sixty seconds, and returns a prioritised list rather than a wall of raw output. Run it on your domain, fix what it finds, then decide whether you need the deeper levels.
