You ran a security scan on your website and got a grade. Maybe it's an A. Maybe it's a D. Either way, you're probably wondering: what does this actually mean? Is my site about to get hacked? Are my visitors at risk?
The short answer: a website security score is a snapshot of how well your site follows publicly recommended security best practices. It doesn't mean you've been breached. It means there are things any browser or any visitor can check about your site and some of them could be configured better.
Let's break it down.
What a security score measures
A website security score evaluates the publicly visible configuration of your website. This isn't about scanning your server's file system or testing for SQL injection. It's about what your site tells every single visitor's browser when they connect.
Think of it like a building inspection. An inspector doesn't break into your vault — they check whether the doors lock properly, the fire exits work and the smoke detectors are installed. A security score does the same thing for your website.
Most scanners, including Guardr — evaluate five main areas:
1. TLS / SSL configuration
TLS (Transport Layer Security) is what makes your site load over HTTPS instead of HTTP. But not all TLS setups are equal. A security scan checks whether your certificate is valid, whether outdated protocol versions like TLS 1.0 and 1.1 are disabled and whether the connection between your visitor and your server is properly encrypted.
A properly configured TLS setup also means your SSL certificate isn't about to expire without you knowing. Expired certificates trigger browser warnings that immediately drive visitors away — and most site owners don't realize it happened until someone tells them.
Why it matters: A weak or misconfigured TLS setup can leave your visitors' data exposed in transit — login credentials, form submissions, payment information. And an expired certificate can take your site's credibility offline in seconds.
2. Security headers
Security headers are instructions your server sends to the browser with every page load. They tell the browser things like: "don't load scripts from unknown sources," "don't allow this page to be embedded in an iframe," and "always use HTTPS."
The most important ones include:
Strict-Transport-Security (HSTS) — forces HTTPS connections, preventing downgrade attacks where an attacker intercepts the initial HTTP request before it redirects to HTTPS.
Content-Security-Policy (CSP) — controls which resources the browser is allowed to load, blocking malicious scripts injected through cross-site scripting (XSS) attacks.
X-Content-Type-Options — prevents the browser from guessing file types incorrectly, which attackers can exploit to execute malicious code disguised as harmless files.
X-Frame-Options — blocks clickjacking attacks by preventing your site from being embedded in iframes on malicious pages.
Referrer-Policy — controls what information is shared when visitors click links on your site, preventing sensitive URL parameters from leaking to third parties.
Permissions-Policy — restricts which browser features (camera, microphone, geolocation) your site can access, reducing the attack surface if your site is ever compromised.
Why it matters: Missing security headers are the single most common misconfiguration on the web. They're free to add, take minutes to configure and protect your visitors from entire classes of attacks. If you fix nothing else, fix your headers first.
3. Cookie security
If your site sets cookies (and almost every site does — analytics, sessions, preferences), those cookies should be configured with security flags: Secure (only sent over HTTPS), HttpOnly (not accessible to JavaScript) and SameSite (prevents cross-site request forgery).
Without these flags, cookies become low-hanging fruit for attackers. A cookie without the Secure flag can be intercepted over an unencrypted connection. A cookie without HttpOnly can be stolen by a malicious script running on your page. A cookie without SameSite can be exploited in cross-site request forgery (CSRF) attacks, where an attacker tricks your user's browser into making authenticated requests to your site.
Why it matters: Insecure cookies can be stolen or manipulated, potentially letting an attacker hijack a user's session and act as if they were that user.
4. DNS security
Your domain's DNS configuration can include additional security layers that most site owners overlook. DNSSEC (Domain Name System Security Extensions) prevents attackers from redirecting your visitors to a fake version of your site by cryptographically signing your DNS records. CAA (Certificate Authority Authorization) records specify which certificate authorities are allowed to issue certificates for your domain, preventing unauthorized certificate issuance.
These are often ignored because they're configured at the registrar level, not the server level — meaning they fall through the cracks between "the person who manages the domain" and "the person who manages the server."
Why it matters: Without DNS security, an attacker could intercept your visitors before they even reach your server — and your visitors would have no way to tell the difference.
5. Exposure and information leakage
This category checks whether your site exposes files or paths that shouldn't be publicly accessible — things like .git directories, .env files, wp-admin login panels, database backup files, or server information headers that reveal your technology stack.
Every piece of exposed information makes an attacker's job easier. A leaked .env file could contain API keys, database credentials, or third-party service tokens. An exposed .git directory could reveal your entire source code. A visible wp-admin path confirms you're running WordPress and tells attackers exactly where to focus their brute-force attempts.
Why it matters: Exposure paths give attackers a roadmap of your infrastructure. The less they know about your stack, the harder their job becomes.
How the score is calculated
Different scanners weigh these categories differently. In Guardr, the weighting reflects real-world impact:
TLS / SSL: 28% — because encryption is foundational to everything else.
Security Headers: 28% — because they're the most actionable and commonly missing.
Exposure Paths: 20% — because information leakage creates direct, exploitable risk.
Cookie Security: 14% — because session security matters for any site handling user data.
DNS Security: 10% — because it's important but less commonly exploited at the SMB level.
Each category is scored individually based on what's configured correctly versus what's missing or misconfigured. The category scores are then combined into an overall percentage that maps to a letter grade:
| Score | Grade | What it means |
|---|---|---|
| 90–100 | A | Excellent — your site follows best practices across the board |
| 80–89 | B | Good — solid foundation with a few misconfigurations to address |
| 65–79 | C | Fair — noticeable gaps that should be fixed soon |
| 50–64 | D | Poor — significant misconfigurations putting visitors at risk |
| Below 50 | F | Critical — immediate attention needed |
Most websites score in the C to B range. If you're there, you're not alone — but you can do better.
What a score doesn't tell you
It's important to understand the limits of a security score:
It's not a penetration test. A score checks configuration, not whether an attacker can exploit a specific vulnerability in your application code or business logic.
It's not a guarantee. An A grade means your publicly visible configuration follows best practices. It doesn't mean your site is unhackable — there is no tool that can promise that.
It's not permanent. Configurations change when you update your server, switch hosting providers, deploy new code, or modify your tech stack. A score from last month might not reflect today's reality.
It's not a compliance certificate. While a good security score aligns with many compliance requirements (PCI DSS, GDPR technical measures), it doesn't replace a formal compliance audit.
This is exactly why continuous monitoring matters — a one-time scan tells you where you stand right now, but your security posture can drift without anyone noticing.
What to do with your score
If your score isn't where you'd like it to be, here's the good news: most misconfigurations are straightforward to fix. You don't need to hire a security consultant or overhaul your infrastructure.
Start with the highest-impact items:
Security headers — these are usually the quickest wins. Adding headers like HSTS, X-Content-Type-Options and X-Frame-Options takes minutes on most platforms.
TLS configuration — make sure you're running TLS 1.2 or higher and that your certificate is valid and not approaching expiry. If you're on Cloudflare or a modern hosting provider, most of this is handled for you but it's worth verifying.
Cookie flags — if you control your application's cookie settings, adding Secure, HttpOnly and SameSite flags is usually a small code change or server configuration update.
Exposure paths — check whether any sensitive files (.env, .git, backups) are publicly accessible and block them at the server level with deny rules.
DNS security — enable DNSSEC through your domain registrar and add CAA records to restrict certificate issuance. This is a one-time setup that takes about 10 minutes.
Each fix compounds. Address the top three items and you'll likely jump an entire letter grade.
Why continuous monitoring beats one-time scans
Running a scan once is useful. It gives you a baseline. But websites are not static — you deploy new code, update plugins, switch CDN providers, renew certificates, change server configurations. Any of these can quietly alter your security posture without triggering a single alert.
A header that was present last week might disappear after a deployment. A certificate that was fine yesterday might expire tomorrow. A new exposed path might appear when a developer pushes a config file they didn't mean to.
Continuous monitoring catches these changes before they become problems. Instead of remembering to manually check your site every few weeks (and let's be honest, you won't), you get alerted the moment something changes: a header disappears, a certificate is approaching expiry, your score drops.
That's exactly what Guardr is built for. It scans your site on a regular schedule, tracks changes over time and alerts you when something needs attention — so you can fix misconfigurations in minutes instead of discovering them weeks later.
A security score is a starting point, not a destination. It tells you where you stand, highlights what needs attention and gives you a clear path to improving. The sites that stay secure aren't the ones that scan once and forget — they're the ones that monitor continuously and fix issues as they appear.
Top comments (0)