How to read your scan results and fix the issues
You scanned your site and see a grade and a list of issues — now what? We explain every finding type and show how to fix it, concretely.
You scanned your site with our scanner, saw a “C” grade, a “medium” risk level and a list of a dozen or so issues — now what? The score alone is only half the story; the value appears when you turn it into concrete fixes. This guide walks through the report step by step: what the result means, how to prioritise and how to fix each finding type. Most fixes are changes to server or DNS configuration — doable in a few to a dozen minutes.
First, understand the score, grade and risk
The scanner produces three related values:
- Score (0–100) — starts at 100 and drops for missing protections. It’s a general hygiene indicator.
- Grade (A–F) — a letter that’s a shorthand for the score, handy for quick comparison.
- Risk level (low/medium/high) — an approximate weight of the issues.
The key rule: prioritise by finding severity, not by list order. The scanner sorts issues from most serious — start at the top. Fix “critical” and “high” findings first; “low” and “info” ones can wait.
Fixing issues, type by type
No HTTPS or HTTP→HTTPS redirect
This is the most serious problem. If the site doesn’t enforce an encrypted connection, user data is exposed in transit. Fix: install a TLS certificate (free Let’s Encrypt) and configure a redirect of all HTTP traffic to HTTPS (301). It’s the foundation — without it, the rest matters less.
Missing security headers
The most common finding category. You add each header in server configuration (nginx/Apache) or at the app/CDN level:
- Content-Security-Policy — restricts script sources; the biggest protection against XSS, but needs tailoring to the site (start in report-only mode).
- Strict-Transport-Security (HSTS) — enforces HTTPS in the browser; set at least 6 months with
includeSubDomains. - X-Frame-Options: DENY (or CSP
frame-ancestors) — blocks clickjacking. - X-Content-Type-Options: nosniff — blocks content-type guessing.
- Referrer-Policy — e.g.
strict-origin-when-cross-origin. - Permissions-Policy — disables unused browser APIs (camera, microphone).
We covered headers and their meaning in more depth in the context of OWASP Top 10.
Cookies without Secure / HttpOnly / SameSite flags
If the scanner reports a cookie without flags: Secure (sent only over HTTPS), HttpOnly (inaccessible to scripts — protects against session theft via XSS) and SameSite (protection against CSRF). Set them in the application config for session cookies. It’s a quick and valuable fix.
Email problems: no SPF / DMARC
If the scanner shows no SPF or DMARC, your domain is easier to spoof in email. Fix: add an SPF record pointing to allowed servers, enable DKIM at your mail provider and deploy DMARC — starting at p=none (monitoring), and ultimately p=quarantine/p=reject. We described the whole process in the SPF/DKIM/DMARC guide.
Sensitive file exposure (.git, .env)
This is the most dangerous of the “configuration” findings. A publicly accessible .git directory or .env file can reveal source code, passwords and keys. Fix immediately: block access to these paths in server configuration, and if secrets were exposed — rotate them (change passwords, API keys), because they may already have been stolen.
Library vulnerabilities (outdated JS versions)
The scanner detected an old library version (e.g. jQuery, Lodash) with known CVEs. Fix: update the library to the latest version. It’s the same mechanism as in broader vulnerability management — outdated components are one of the most common attack routes.
Server and email address exposure
Server and X-Powered-By headers leaking a version make it easier for an attacker to choose an exploit — hide the version in configuration. Email addresses detected in content may be harvested by bots (spam, phishing) — consider contact forms instead of plain addresses. These are lower-weight findings, but worth closing.
After fixing: rescan
Once you’ve deployed the fixes, run the scan again and compare the result. The scanner is stateless, so it keeps no history — if you want to track progress, download the JSON report before and after your changes. A rising score and disappearing findings are the best proof the fixes worked.
When a scan isn’t enough
A passive scanner closes the configuration visible from outside, but there are things it won’t find: business logic flaws, access control gaps (a user sees someone else’s data), or vulnerabilities like SQL injection or XSS that require active testing. If your site processes customer data, handles payments or user logins, it’s worth complementing the scan with a manual penetration test — that’s what finds the gaps a scanner misses.
Frequently asked questions (FAQ)
I got a “C” — is that bad? Not necessarily terrible, but there’s room to improve. A “C” usually means working HTTPS but gaps in headers or cookies. The good news: those are typically the cheapest fixes (a few lines of config) that quickly raise the score and real resilience.
Where do I start if there are many issues? At the top of the list, i.e. the most serious: first HTTPS and the redirect, then CSP and the other headers, sensitive file exposure (if detected — that’s a priority), and finally minor items like server version exposure. The scanner already sorted findings by severity.
I fixed everything but the score isn’t 100 — why? Some findings are informational (e.g. no security.txt, detected technologies) and can’t always be “fixed” or aren’t always worth it. The goal isn’t an artificial 100/100 but closing real gaps. A score around A with high- and medium-weight issues closed is a very good result for a passive scan.
Do the fixes require a developer? Most (headers, cookies, SPF/DMARC, blocking paths) are server or DNS configuration changes — an admin or whoever manages the hosting can handle them. More complex ones (tailoring a CSP, updating libraries in the app) may need a developer.
I want to be sure I didn’t miss anything — can you help? Yes. After closing the gaps yourself, it’s worth verifying the whole independently. An audit or penetration test checks what a passive scan doesn’t cover. Book a free consultation and we’ll help match the scope to your site.
Summary
A scan result is only valuable once you turn it into fixes. Start with the most serious findings (HTTPS, file exposure, CSP), fix in order of severity, and after your changes rescan to confirm the effect. Most gaps you’ll close in configuration within minutes. And when you want to be sure nothing is hidden beneath the surface — complement the scan with a manual test. Scan your site and get to work on the list.
The scanner runs passively and statelessly. A manual penetration test gives the full risk picture. Let’s talk.
