Website security report example: a real check

About this check

Item	As reported
Site	corsairslegacy.com, a site we own
Checked	27 Oct 2026, 12:35-12:36 UTC (1 min 17 s)
View	Free check: the view anyone gets without verified ownership. Results of the owner-only checks (active port scan, deep API audit) are shown only to a verified owner, so none of them are on this page. Network ports in this view come from passive data only.
Hosts	4 found, all 4 checked
Checks	233 of 233 finished
Evidence	544 evidence points; 12 technologies detected
Summary	Built by fixed rules from the evidence. No AI model was used.

This page is a snapshot of that day. Results change over time: the site changes, and so do our checks, so a new check of the same site can give different results.

Score and coverage

Score: 80 out of 100, where higher is safer. Risk rating: Critical risk. On its own, a score of 80 would read as Low risk. The report shows Critical risk because 1 finding has the top level, and it says to start with that one.

Coverage: all 233 checks finished. Of the checks that applied to this site, 87% were fully assessed and 100% at least partly. Lower coverage means more blind spots, not more risk.

Findings: 23 unique issues, 1 High, 7 Medium and 15 Low. The report lists 22 of them as rows (1 High, 7 Medium, 14 Low): the counter and the list are built slightly differently, and the list has a row limit. All 22 listed rows are below, grouped by area.

Levels: on this page we use High, Medium and Low. In the report the same three levels appear as Critical, Attention and Info. “Where” gives the number of hosts with the finding; we do not name hosts other than the main domain.

Outdated software: 2 findings

Finding	Level	Where	What it means and what to do
A component version that matches a known exploited vulnerability	High	Main domain	Details are not shown in this sample. A version match seen from outside is not proof; the report marks it as potentially affected and says to deal with it first.
A component version that matches a published security advisory	Medium	Main domain	Details are not shown in this sample. Also a version match, not proof.

How version matching works in general: outdated software check.

TLS and HTTPS: 3 findings

Finding	Level	Where	What it means and what to do
TLS 1.0 still accepted	Medium	4 hosts	An old protocol version that RFC 8996 says must no longer be used still works. Turn off TLS 1.0 and 1.1 and keep TLS 1.2 and 1.3. Modern browsers no longer use the old versions.
TLS 1.1 still accepted	Medium	4 hosts	Same as above for TLS 1.1. One change of the minimum TLS version fixes both findings.
Missing HSTS header	Medium	4 hosts	Browsers are not told to use only HTTPS for these hosts, so a visit that starts on http:// can be intercepted on an untrusted network. Add the `Strict-Transport-Security` header (example card below).

Cookies and browser security controls: 4 findings

Finding	Level	Where	What it means and what to do
Session cookie missing Secure/HttpOnly/SameSite	Medium	2 hosts	A session-like cookie is set without its hardening flags. These flags keep a cookie off unencrypted connections, out of reach of page scripts, and out of most requests from other sites. Turn them on in the application or web server settings.
Missing Content-Security-Policy	Low	4 hosts	Its absence is not a vulnerability by itself, but a policy limits the damage of injected scripts. Start with a Report-Only policy, collect reports, then enforce it.
Missing X-Content-Type-Options	Low	4 hosts	Browsers may guess file types. Add `X-Content-Type-Options: nosniff` to every response (example card below).
Missing clickjacking protection	Low	4 hosts	Other sites could show these pages inside a frame. Add the CSP directive `frame-ancestors` or `X-Frame-Options`.

Exposure checks: 3 findings

Finding	Level	Where	What it means and what to do
A publicly readable internal file	Medium	2 hosts	Details are not shown in this sample.
A gap in protection against automated abuse	Medium	2 hosts	Details are not shown in this sample.
Public emails exposed for harvesting	Low	2 hosts	Email addresses appear in plain text on public pages, where scrapers collect them for spam and phishing lists. Use a role address or a contact form; keep the addresses the law requires and filter them for spam.

The full report names the file, the page and the fix for each finding; this sample does not.

Email security: 5 findings

Finding	Level	Where	What it means and what to do
DMARC policy is p=none	Low	Domain	DMARC is set up, but only to monitor: receiving servers are not asked to act on mail that fails the checks. Read the reports for a few weeks, then move to `p=quarantine` (example card below).
DMARC alignment relaxed	Low	Domain	The record uses relaxed alignment, the default, so mail from subdomains of the domain can pass too. A common setting: switch to strict only after the reports show that every service sending your mail signs with the domain itself.
No DKIM on common selectors	Low	Domain	No DKIM key was found under common selector names. If your mail service signs with another selector, nothing needs to change; otherwise turn DKIM signing on.
MTA-STS DNS record missing	Low	Domain	Other mail servers are not told to require TLS with a valid certificate when they deliver mail to this domain. Optional hardening; start in testing mode (RFC 8461).
TLS-RPT DNS record missing	Low	Domain	The owner gets no reports when other mail servers fail to set up TLS to this domain’s mail server. Add a TLS-RPT record with a mailbox someone reads.

Domain and DNS: 2 findings

Finding	Level	Where	What it means and what to do
DNSSEC not observed	Low	2 hosts	DNS answers for the domain are not signed. Hardening, if the registrar and DNS provider support it; it is not a sign of compromise.
No CAA DNS records	Low	2 hosts	Any certificate authority may issue certificates for the domain. Add a CAA record that names the authorities you use.

Inventory notes, no action needed: 3 findings

Finding	Level	Where	What it means and what to do
Client libraries observed on the page	Low	2 hosts	An inventory of the front-end libraries the report recognised on the page. Nothing to do.
Payment gateways detected	Low	2 hosts	A list of the payment services seen on the site. Nothing to do; remove the scripts of services you no longer use.
Payment SDK embed format looks correct	Low	2 hosts	A good result: payment scripts load from official HTTPS addresses, and the page source showed no secret keys. Keep it that way after updates.

We do not name the libraries or the payment services on this page.

Example card: missing HSTS header (Medium)

What we saw: HTTPS responses from all 4 hosts had no Strict-Transport-Security header.
Why it matters: HSTS tells browsers to reach a site only over HTTPS for a set time. Without it, a visit that starts with an http:// link or a typed address can be intercepted on an untrusted network before the redirect to HTTPS.
What to do: add Strict-Transport-Security: max-age=31536000 to HTTPS responses on every host, one line in the web server or CDN settings. Add includeSubDomains and preload only once every subdomain serves HTTPS. Server admin, about 10 minutes.
How to check: curl -sI https://<your-domain> | grep -i strict-transport-security should print the header.
Confidence: confirmed observation of the response headers.

Source: RFC 6797: HTTP Strict Transport Security (HSTS).

Example card: missing X-Content-Type-Options (Low)

What we saw: responses from all 4 hosts had no X-Content-Type-Options: nosniff header.
Why it matters: without it, browsers may guess the type of a file instead of trusting the type the server declares. The header turns that guessing off, so a file is not treated as something it is not.
What to do: add X-Content-Type-Options: nosniff to every response, one line in the web server configuration, and make sure files are served with the right Content-Type. Server admin, about 5 minutes.
How to check: curl -sI https://<your-domain> | grep -i x-content-type-options should print nosniff.
Confidence: confirmed observation of the response headers.

Source: OWASP: HTTP Headers Cheat Sheet.

Example card: DMARC policy is p=none (Low)

What we saw: the domain publishes a DMARC record, but its policy is p=none, which only monitors.
Why it matters: with p=none the domain owner asks receiving servers to take no specific action on mail that fails DMARC, so the policy does not stop mail forged in the domain’s name. It is a good first step, because the reports show who sends mail for the domain.
What to do: make sure the record has a report address (rua=mailto: plus a mailbox you read). After two to four weeks of reports, when every legitimate sender passes, move to p=quarantine. DNS admin, about 15 minutes.
How to check: dig +short TXT _dmarc.<your-domain> shows the current policy.
Confidence: confirmed observation from public DNS.

Source: RFC 7489: DMARC, since obsoleted by RFC 9989, 9990 and 9991.

What this page leaves out

Host names other than the main domain, paths, and the evidence behind each finding.
Every detail of the four findings marked “Details are not shown in this sample”.
The technologies, IP addresses, hosting and mail details from the public domain records.
Page speed, legal documents and AI crawler access, which the full report also covers.

Questions

Why is this a copy and not a live report?

A live report shows host names, paths and evidence that could help an attacker. This page is a dated, redacted copy, so it stays the same while the site changes.

Why is the risk rating Critical when the score is 80?

The score sums up every check. The risk rating also takes the most serious open findings into account: in this report, the one finding at the top level sets it to Critical risk, and the report says to start with that finding.

Why do some findings have no details?

This is a live site. Some findings point to something an attacker could use, so this sample keeps them in the counts and levels but leaves out what and where they are. The report of your own site shows the details of each listed finding.

Will my report look like this?

The structure is the same. Your findings, score and coverage depend on your site. If you verify ownership of your site, you also see the results of the owner-only checks.

Sources

RFC 8996: Deprecating TLS 1.0 and TLS 1.1 rfc-editor.org
RFC 6797: HTTP Strict Transport Security (HSTS) rfc-editor.org
OWASP: HTTP Headers Cheat Sheet cheatsheetseries.owasp.org
OWASP: Session Management Cheat Sheet cheatsheetseries.owasp.org
RFC 7489: DMARC rfc-editor.org
RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) rfc-editor.org

Sample report: a real check of our own site