What a Website Security Audit Report Looks Like

Originally published on the Bug Circuit blog.

A website security audit report is a document that lists every vulnerability a human tester found on your site, ranked by how dangerous it is, with proof it's real and exact steps to fix it — not a scanner printout of vague warnings.

This is for anyone about to pay for a security audit (ours or anyone else's) who wants to know what they're actually buying before they hand over a card number. Below is a real, annotated sample report structure with example findings, so you can see exactly what a manual audit produces — and what to be suspicious of if a report doesn't look like this.

The three parts every real report has

A legitimate manual audit report has three sections, in this order:

1. Executive summary — one page, plain English, no jargon. What was tested, how many issues were found at each severity, and the overall risk picture in 3-4 sentences a non-technical owner can read in 30 seconds.
2. Findings list — every individual vulnerability, one at a time, each with the same fields (below). This is the bulk of the report.
3. Fix guidance — for each finding, the exact change to make: a setting to flip, a line to add to a config file, a plugin to update, code to patch.

If a report you're evaluating skips straight from a summary to a generic "harden your site" checklist with no specific findings tied to your actual site, it wasn't a real audit of your site — it was a template.

Anatomy of one finding, annotated

Here's what a single, real finding looks like inside the report, field by field.

Field	What it means	Example from a real finding
Title	Short name for the issue	Missing HTTP security headers on all pages
Severity	How bad it is if left unfixed (table below)	Medium
Location	The exact URL, page, or endpoint affected	https://example.com/* (site-wide)
Description	What the problem is, in plain English	Your site doesn't send a Content-Security-Policy or X-Frame-Options header, so a browser has no instructions to block malicious scripts or clickjacking attempts if an attacker manages to inject content.
Evidence	Proof it's real — a screenshot, a response header dump, a request/response pair	curl -I https://example.com response showing no Strict-Transport-Security, X-Content-Type-Options, or Content-Security-Policy headers present
Impact	What an attacker could actually do with it	An attacker who finds a second, smaller bug (like a comment field that isn't sanitized) could chain it with this gap to run scripts in your visitors' browsers or embed your login page in an invisible iframe to steal credentials
Fix	The exact change to make	Add these headers via your server config or CDN: Content-Security-Policy: default-src 'self', X-Content-Type-Options: nosniff, Strict-Transport-Security: max-age=31536000; includeSubDomains, X-Frame-Options: DENY
Reference	Where to read more	OWASP Secure Headers Project

Every finding in a real report has all eight of those fields. If a "finding" is just a sentence with no evidence and no exact fix, that's filler, not an audit result — it's padding a page count, not proving a risk. You can check your own headers right now with our security headers scanner to see where you'd land before paying for anything.

How severity is actually decided

Severity isn't a vibe — it's based on how easy the bug is to exploit and how much damage it causes. Most manual auditors (us included) follow the same logic as the industry-standard OWASP Risk Rating Methodology, which weighs exploitability against impact.

Severity	What it means	Typical example	Fix urgency
Critical	Actively exploitable, no login required, major damage (data theft, full takeover)	SQL injection on a login form; exposed .env file with database credentials	Fix within 24-48 hours
High	Exploitable with some effort or partial access; serious damage	Admin panel reachable with a default or weak password; outdated plugin with a public, known exploit	Fix within a week
Medium	Requires specific conditions or user interaction; moderate damage	Reflected cross-site scripting (XSS) in a search field; missing security headers	Fix within a month
Low	Hard to exploit or limited impact on its own	Verbose server error messages revealing software versions	Fix when convenient
Informational	Not a vulnerability, but worth knowing	TLS certificate expiring in 60 days	No action required now, just a heads-up

For the specific mechanics of an issue like reflected XSS, OWASP's cross-site scripting page is the primary reference auditors cite — a good report should link to sources like this instead of just asserting "this is dangerous, trust us."

A short sample findings list, as it would appear in a report

Here's what the findings section of a real small-business site report might contain — condensed:

• [Critical] Publicly accessible .env file exposing database credentials — https://example.com/.env returns the raw file instead of a 404. Contains database username, password, and API keys in plain text. Fix: block dotfiles in your web server config (e.g., Apache: <FilesMatch "^\.">Require all denied</FilesMatch>) and rotate every credential in the file immediately.
• [High] Outdated WordPress plugin with a known, public vulnerability — Contact Form 7 running an old version with a documented flaw listed in the NVD database. Fix: update to the current version via WordPress admin → Plugins, or remove the plugin if unused. Check CISA's Known Exploited Vulnerabilities catalog for anything actively being used in real attacks.
• [Medium] Login page has no rate limiting — An attacker can attempt unlimited password guesses against /wp-login.php with no lockout. Fix: install a login-attempt limiter (e.g., Limit Login Attempts Reloaded) or add rate limiting at the server/CDN level.
• [Low] Server reveals its exact software version in error pages — Gives an attacker a head start on picking which known exploits to try. Fix: disable detailed error output in production (display_errors = Off in PHP, or the equivalent in your framework).

Notice each one names a real, specific location on the actual site — never "your site may be vulnerable to XSS somewhere." That specificity is the entire value of paying a human instead of running a free scanner yourself.

Manual report vs. automated scanner printout

The biggest giveaway of a low-effort "audit" is that it's just an automated scan with a cover page. Automated tools are useful and we use them too, but on their own they flag lots of things that aren't actually exploitable, and they miss logic flaws entirely — like a checkout page that lets you edit the price in a hidden form field, or an account page that shows another customer's order if you change a number in the URL. Those require a person actually clicking around and thinking like an attacker. We cover the difference in more depth in our guide to manual vs. automated penetration testing if you want the full breakdown.

Checklist: is the report you're about to pay for real?

Before you pay for any audit, check the sample report (a legitimate vendor will show you one) against this:

• [ ] Every finding names an exact URL or location on your actual site — not a generic statement
• [ ] Every finding includes evidence (screenshot, header output, or request/response)
• [ ] Every finding has a severity rating with a stated reason, not just a color
• [ ] Every finding includes a specific fix, not "contact a developer"
• [ ] The report cites external references (OWASP, CISA, NVD) for technical claims
• [ ] There's an executive summary a non-technical owner can actually understand
• [ ] The vendor tells you plainly what was and wasn't tested (scope)

If you're not sure whether your site even needs this yet, our free website security check gives you a fast passive read and a plain yes/no on anything critical, no card required — and if you want to understand the risk picture in general first, our guide on how to tell if your website is hackable walks through the warning signs.

Key takeaways

• A real audit report has three parts: executive summary, individual findings, and specific fixes — not just a scanner printout.
• Every finding should include eight things: title, severity, exact location, description, evidence, impact, fix, and a reference.
• Severity should follow a defined methodology (like OWASP's Risk Rating Methodology), not a gut feeling.
• Manual testing catches logic flaws (like editable prices or exposed other-customer data) that automated scanners miss entirely.
• Ask to see a sample report before paying for any audit — a real vendor will show you one without hesitation.

If you want to see this done on your own site instead of a sample, Circuit is a $49 one-time manual audit: a real person tests your site and hands you a report built exactly like the one above, with every finding tied to your actual pages and evidence attached — no subscription, no upsell pressure, just the report.