Website Security Audit Guide: Work Through a Site Check in Order

A website security audit is a systematic look at a site's defences, done before an attacker does the same thing without permission. It is not a single scan or a single score. It is a sequence of checks, each answering a specific question: is the connection encrypted, are the security headers present, are forms protected, are cookies set safely, is access controlled, and is third-party content trustworthy? Done in order, the checks build a picture of the site's real exposure. Done randomly, they produce a pile of findings nobody can prioritise.

The Website Security Audit tool works through a site's security checks and reports what it finds, page by page and control by control. It examines the site's observable security posture: the headers it sends, the certificate it presents, and the configuration it exposes. It does not log in as a user, test for vulnerabilities by attacking the site, or read private data. That boundary matters: an audit tool observes and reports, and the deeper testing that simulates attacks belongs to specialists with explicit permission. What the audit gives you is the ordered, evidence-based list that turns vague worry into specific work.

Order matters because findings interact. A missing security header on a page that also serves over an unencrypted connection is a different problem from the same header missing on a properly encrypted page. A form without protection on a public contact page is a different problem from the same flaw on a password-change form. Working in a fixed order, from the broadest protections to the narrowest, keeps the audit from drowning in details before the big questions are answered, and it makes two audits of the same site comparable, because the same checks run in the same sequence each time.

What to know before you start

First, inventory the site. List the pages that matter: the home page, the main content pages, every form, every login or account page, and every page that embeds third-party content. Note which pages handle sensitive data, such as passwords, payments, or personal information, because those pages deserve the strictest checks. An audit that only examines the home page is a home-page audit, not a site audit, and the pages it skipped are exactly where problems prefer to live.

Second, check transport security. Confirm the site loads over an encrypted connection, that the certificate is valid and covers the site's addresses, and that unencrypted requests redirect to the encrypted version. A certificate that expired last week, or one that covers the wrong domain, breaks trust for every visitor and every page at once, which is why this check comes before the finer ones. While here, note whether the site sends a strict transport header, which tells browsers to use the encrypted version in future, and whether old, weak protocol versions are still accepted.

Third, check headers and cookies. Security headers are instructions a site sends with each page, telling browsers how to behave: whether the page may be framed by another site, which sources may load scripts and styles, and whether browsers should block content that looks like an attack. Missing headers are common and often easy to fix, but each one should be judged on the page it protects, because a strict policy that breaks a legitimate embed is a fix that creates a new problem. Cookies get the same treatment: check that session and sensitive cookies carry the flags that keep them out of scripts and restrict them to encrypted connections, as described in the Cookie Security Checker Guide.

Fourth, check forms, access, and third parties. Every form should be examined for what it accepts and what it reveals: error messages that confirm whether an account exists, forms that accept input without validation, and login pages without protection against repeated guessing. Access checks ask who can reach administrative pages and whether that access is genuinely restricted. Third-party checks ask which external scripts and embeds run on each page and whether each one is still needed, because every embed is code you did not write running with your site's privileges.

A worked example you can follow

Take a sample small site with 20 pages, 4 forms, and 1 login page. Suppose the audit returns 14 findings: 6 missing headers, 3 cookie flags, 2 form issues, 2 outdated embeds, and 1 certificate warning. The first job is not to fix all 14 but to sort them. The certificate warning affects all 20 pages, so it ranks first despite being a single item. The 2 form issues affect the login and contact forms, so they rank next. The cookie flags affect logged-in visitors, so they follow. The headers and embeds, which harden the site but do not expose data directly, come after. Sorting 14 findings this way turns a list into a plan: 1 certificate fix, then 2 form fixes, then 3 cookie fixes, then 8 hardening items.

Now count the coverage. The audit examined 20 pages and found header issues on 12 of them, which is 60 percent of the site. If the header fix is applied site-wide through the server configuration, one change fixes all 12 at once, and a re-audit should show the header findings fall from 6 to 0. If instead the fix is applied page by page, the same result takes twelve edits and invites a thirteenth page to be missed. The audit's page-level detail tells you where the problem is; the pattern across pages tells you where the fix belongs. Always prefer the fix at the level where the problem originates.

A second sample shows why re-auditing matters. Suppose the first audit found 14 findings and the fixes addressed 12, leaving 2 deferred because they required a provider change. A re-audit should show 2 findings, both previously known, and nothing new. If it shows 5, three are either regressions from the fixes or problems the first audit missed, and both possibilities deserve investigation before the audit is declared complete. The re-audit is not bureaucracy; it is the evidence that the work worked.

Common mistakes to avoid

The first mistake is auditing only the home page and calling it a site audit. The second is treating the audit as a score to maximise rather than a list to work through: a site can improve its score by fixing trivial items while leaving a serious one untouched, and the score will look better while the risk stays the same. The third mistake is fixing findings without understanding them, especially headers, where a copied policy from another site can break legitimate features. Read what each header does before applying it, and test the pages it affects.

The fourth mistake is never re-auditing. An audit is a snapshot, and sites change: new pages, new embeds, new forms. A finding fixed in August can regress in September when a template changes. Schedule re-audits after significant changes and on a regular cadence, and keep the old reports so regressions are visible instead of debatable.

Checking the result before you finish

A complete audit ends with four artefacts: the inventory of pages checked, the findings with page and evidence for each, the severity-sorted fix list with owners, and the re-audit that confirms the fixes. Keep all four together, dated, so a future question about what was checked and what was fixed has a documentary answer. Share the fix list with the people who can act on it, in plain language, because a finding written only for specialists will wait for a specialist to translate it.

For companion checks, the SSL Certificate Checker tool examines certificates in detail, the HTTP Security Headers Guide explains each header, and the On-Page SEO and Redirect Checker tool covers the overlapping ground of page health. Do not paste secrets into any audit tool: audits need observable site behaviour, never passwords, keys, or session tokens. An audit done in order, fixed in order, and re-checked after fixing is the most reliable security habit a small site can have.