Website Security Audit Report Builder

Build a presentable security report from audit data - scope, executive summary, evidence, remediation - as print-ready HTML, Markdown or JSON, with a check for sensitive fields before you share it.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Audit result (JSON) The JSON the Website Security Audit exports. Read in your browser.

Or drop the audit JSON file

Up to 16 MB. Read locally.

Report title

Prepared for

Prepared by

Mask sensitive values in the evidence Include evidence at all Include passing checks Masking is on by default. A report is the artefact that gets forwarded.

The evidence is the part that leaks

A security report is the one artefact of an assessment that travels. It gets emailed to a client, attached to a ticket, dropped into a shared drive and forwarded to someone who was never in the original conversation. Whatever is in it is now in all of those places.

The evidence section is what makes that a problem. Raw audit evidence contains cookie names and values, header values, internal hostnames, private addresses and exact software versions - which is to say, a shopping list. So evidence is scanned and masked before the report is written:

Cookie values, bearer and basic credentials, JSON web tokens
API key shapes - Stripe, GitHub, Slack and AWS key prefixes - and PEM private key blocks
Email addresses
Internal hostnames (.internal, .corp, .lan and similar) and RFC 1918 addresses
Exact software versions, which turn a report into a lookup against a vulnerability database

Each masked value is replaced with a visible marker rather than deleted, so a reader can tell the difference between "this was redacted" and "there was nothing here". Masking can be turned off, and when it is, the tool says exactly what the report is about to publish before you download it.

The summary says what was not measured

The executive summary states the score, then states the gaps. An audit where four checks timed out has not produced a score of 91 - it has produced a ceiling of 91 with four unanswered questions, and a summary that omits that is how a partial assessment becomes a sign-off.

Checks that did not run are listed by name under their own heading, with the note that they are gaps rather than passes. The scope section is equally direct about what an external configuration audit cannot see: authentication logic, authorisation, business logic and everything behind a login.

The output is a real file, not a screenshot

The HTML report is entirely self-contained - no external stylesheet, no script, no web font, no network reference of any kind. A report that fetches a font when it is opened tells the font host who read it and when, which is not a property a security report should have. It prints cleanly to PDF, and Markdown and JSON exports are available for anyone feeding it into another system.

Frequently asked questions

Can I include the raw evidence?

Yes, by turning masking off - but the tool will tell you precisely which categories of sensitive value the report is about to contain first. There are legitimate reasons to do it; doing it without noticing is not one of them.

Why exclude passing checks by default?

Because a report padded with everything that is fine buries what is not. They can be included with one checkbox when the point of the report is to evidence coverage rather than to drive work.

Does the PDF export upload anything?

No. The report is built in your browser and printed from a local document. There is no server-side rendering step and nothing is transmitted.

Will it read an older audit export?

Yes. Any schema version 1.x document, plus exports made before schema versioning existed, which are upgraded automatically. A document from a newer major version is refused rather than guessed at.

Is my audit result uploaded?

No. Reading, building and exporting all happen in your browser.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system 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.