Website Security Audit

Run one passive scan that combines headers, HTTPS and TLS, the certificate chain, CSP, cookies, CORS, DNS security, email authentication, redirects and mixed content into a single scored report with prioritised fixes.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Domain to audit Enter a domain you own or are authorised to review. Every check is passive and read-only - the same requests an ordinary visitor's browser makes.

What this audit checks

The website security audit runs thirteen passive checks against one domain and combines them into a single scored report. It looks at how the site is served, how it is encrypted, what its response headers instruct the browser to do, how its cookies are scoped, which cross-origin permissions it grants, what it loads from elsewhere, how its DNS is signed, and whether its domain publishes email authentication records.

Every one of those checks is the same code that powers the dedicated tool for it on this site. The audit orchestrates them; it does not reimplement them. That matters because a second implementation would eventually disagree with the first, and you would have no way of knowing which one was right.

The categories, and what each one weighs

Transport and TLS (25%) - HTTPS availability, the HTTP to HTTPS redirect, the negotiated TLS version, certificate expiry, chain validity and HSTS.
Security headers (22%) - Content Security Policy including its own directive warnings, Referrer-Policy and Permissions-Policy.
Cookies and sessions (14%) - the Secure, HttpOnly and SameSite attributes on every cookie the response sets.
Cross-origin and embedding (11%) - COOP, CORP and the CORS configuration, including the credentialed-reflection pattern that quietly defeats the specification's own protection.
Content and third-party code (11%) - mixed content split into active and passive, software version disclosure, and whether a security.txt exists.
DNS and domain (9%) - whether the zone is signed with DNSSEC and whether a validating resolver actually accepts it.
Email authentication (8%) - SPF and DMARC records on the domain.

How the score is calculated

The methodology is published here and versioned, because two of the tools in this suite compare audits against each other and a score that silently changed meaning between them would make both of them lie. This page uses methodology version 1.0, and the version travels in every JSON export.

Every check belongs to exactly one category.
Within a category, each finding costs points by severity: critical 40, high 25, medium 12, unknown 8, low 5. Pass, info and not-applicable cost nothing.
The category starts at 100, the costs are subtracted, and the result is floored at zero.
A category with nothing applicable is dropped entirely and the remaining weights are renormalised - a domain that sends no email is not punished for having no SPF record.
The overall score is the weighted mean of the surviving categories. Grades are A at 90, B at 80, C at 70, D at 60, F below that.

Why "unknown" costs points

If a check applies but its evidence could not be obtained - a responder timed out, a handshake failed - this audit records unknown and charges 8 points for it. That is a deliberate judgement. The alternative is to treat an unanswerable check as a pass, which is how scanners end up flattering the systems they measure, and it would mean a site could score well simply by being hard to reach. An unverifiable control is not a working control.

Not applicable is different and is treated differently. It means the check genuinely does not apply, so it is removed from the calculation rather than counted against the site.

How to read the report

Findings are ordered by severity, so the top of the list is where to start. Each one carries the evidence it was based on - the actual header value, record or status line - and the specific change that fixes it, with configuration for Nginx, Apache and ASP.NET Core where a configuration change is what is needed. Expand Evidence to see what was observed and How to fix it for the remediation.

Export the JSON if you want to keep the result. The Website Security Regression Checker reads that file back and tells you what improved and what regressed since, and the Website Security Remediation Plan turns the findings into assignable work.

Limitations you should know about

This is a passive audit of one page. It reads what the site shows an ordinary visitor and nothing more. It does not log in, submit forms, guess paths, enumerate subdomains or attempt exploitation of any kind, which means there is a large class of real vulnerabilities it structurally cannot find: broken access control, injection flaws, insecure direct object references, business logic problems, and anything that only exists behind authentication.

It also checks the home page, not every page. Cookie and header configuration often differs on authenticated routes, and a clean result here does not guarantee the same settings apply after login. A good score on this audit means the public configuration looked correct at the moment it was checked. It is a floor, not a ceiling, and it is not a substitute for a code review or an authorised penetration test.

Frequently asked questions

Is running this against a site legal or intrusive?

Every request this audit makes is one an ordinary browser makes when someone visits the site: a GET for the home page, a DNS lookup, a TLS handshake. It sends nothing, changes nothing and tests nothing. That said, these tools are built for reviewing systems you run or have been asked to review, and you should use them that way.

Why did my site score lower here than on another scanner?

Most likely because unknown results cost points here rather than being ignored, and because this audit weights transport and TLS more heavily than header checklists do. The full methodology is published above, so you can see exactly which findings produced the number rather than having to trust it.

Does a score of 100 mean my site is secure?

No, and no passive scan can tell you that. It means the configuration this audit can observe looked correct. Application-level security - access control, input handling, business logic - is invisible to every tool of this kind.

Is my domain or the result stored anywhere?

No. The audit runs, the result is returned to your browser, and nothing about the target or the findings is written to a database. The response is marked no-store so it is not held in a shared cache either. Exports are generated in your browser.

Why does it say a check could not be completed?

The audit has an overall time budget so that one slow check cannot hold the whole request open. If a check runs out of that budget it is reported as unknown and named in the report rather than quietly dropped. Run that tool on its own page, where it has a longer budget to itself.

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.