It arrives as a forwarded email with an attachment and one question: "Is our site in danger?" The attachment runs 24 pages, the cover carries a letter grade, and somewhere inside is a crimson 9.8. A client of ours sent us exactly that, produced by a well-known security ratings vendor. Here is how we read it, and how you can read yours.

What 24 pages actually contained

Stripped of packaging, the report held about half a page of actionable content:

  • Five missing security response headers.
  • An X-Powered-By header advertising the server stack.
  • A PHP version banner exposed on one subdomain.

That is a real finding list and it was worth fixing. It is also roughly an afternoon of work, and none of it meant the site was in danger that night. The other 23 and a half pages were presentation.

Six ways a report inflates

  • A critical that is really a string match. The red entry was a CVSS 9.8 hung on that PHP version banner. Nothing was tested. A scanner read the version string, matched it against a vulnerability database, and printed the worst CVE associated with that version. The report's own fine print admitted the CVE only affects 32-bit systems, which no modern host runs. The score was real. Its relevance to this site was zero.
  • Passed checks wearing severity chips. Roughly ten checks in the report had passed, and each still carried a High or Medium chip next to it. Skim the page and you see a column of red and orange. Read the result column and the site is fine. A severity that describes the category rather than your result is decoration, not information.
  • Page speed presented as a security weakness. Four pages were raw Lighthouse performance output, tagged CWE-358 and labeled "Medium (5.0)". Speed is worth improving and we care about it elsewhere. It is not a security weakness, and a slow largest contentful paint does not let anybody into your site.
  • An HTML linter presented as a quality score. A raw W3C validator dump became "Code Quality 62%". Most of the entries were duplicate element IDs, which every site built on a mainstream page builder produces identically. A number was invented from a validator and displayed with the same weight as a security finding.
  • Advice past its expiry date. The remediation list told the client to set X-XSS-Protection. That header has been deprecated for years, current browsers ignore it, and in some configurations it introduced problems of its own. Mozilla's own documentation says not to use it and to rely on Content-Security-Policy instead. Advice ages. A template does not notice.
  • The checks that were not there. Across 24 pages there was no HSTS check at all, on a site where HSTS is one of the highest-value single lines available. There were no WordPress checks either, on a visibly WordPress site: no user enumeration, no xmlrpc.php, no readme or version file probe. A report is only as good as its check list, and a long report with a short list is still a short list.

One more piece of context that never made the cover: the whole website module was 6% of the vendor's overall rating for the company, and it scored a C. A C on 6% of a rating is not a fire. It was laid out with the visual weight of one.

What was genuinely worth fixing

Three things, in this order:

  1. The five missing headers. Behind a CDN this is one rule applied to the zone, or a few lines in the server config otherwise. Minutes, not days.
  2. The X-Powered-By header. One line to remove. It tells attackers what stack to aim at and does nothing for visitors.
  3. The PHP version banner on the subdomain. Turn off the version exposure, and while you are in there, confirm PHP is actually on a supported release. That second part is the one that matters, and no version banner is a substitute for it.

Total: an afternoon, then a re-scan to confirm. The honest summary the client needed was three sentences long, not 24 pages.

Five questions for any audit report

  1. Does each severity come with evidence from your configuration? "Your site returns this header, here is the request" is evidence. "Sites running this version may be vulnerable" is a category, and categories do not have severities for you specifically.
  2. Are passed checks being presented as findings? Count the items that actually failed. If that number is much smaller than the number of colored chips, you are reading a layout choice.
  3. Is anything non-security being scored as security? Performance, HTML validation, spelling and SEO all show up in these reports. They are worth knowing and they are not the same subject. Mixing them inflates the page count and the alarm.
  4. Does every finding name the standard behind it? OWASP, Mozilla web documentation, a CVE number, a CIS benchmark. A finding that cannot say where its rule comes from is an opinion in costume.
  5. Does it tell you exactly what to do? The header, the value, and where it goes. And just as importantly, does it say which fixes it will not make for you, and why? A tool that will happily apply anything has not thought about what it might break.

The honest version

AuditMerlin exists because of reports like that one. Fifteen checks, every finding linked to the OWASP or Mozilla guidance it comes from, passed checks shown as passed, nothing from performance or validation wearing a security label, and a report that says plainly what it is: a technical security audit, not a compliance certificate. Where a fix is genuinely risky to apply blind, like Content-Security-Policy, we say so and give you the rollout path instead of a switch.

Run a free scan and hold it next to whatever landed in your inbox. If the other report is longer than ours and tells you less, you now know exactly which pages to skip.