DEV Community: Guardr

Hardenize moved to $5K+/year enterprise. Here's the self-serve alternative.

Guardr — Mon, 23 Mar 2026 19:33:00 +0000

This post originally appeared on guardr.io/blog/vs-hardenize.

Hardenize was one of the best tools for tracking security posture across a portfolio of websites. After Red Sift acquired it, the self-serve tier was removed and pricing moved to $5,000+/year — aimed at enterprise security teams, not agencies or freelancers.

If you were on the self-serve tier, this post is for you.

What you're probably looking for

A replacement that covers the same monitoring surface as Hardenize:

Security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy)
TLS and SSL certificate expiry — alerts at 30 and 7 days before expiry
DNS security (DNSSEC, CAA records)
Cookie attribute checks (Secure, HttpOnly, SameSite)
Exposure path detection (.git, .env, wp-login.php, phpinfo.php)
Continuous monitoring with alerts — not manual spot checks

...without a $5K/year contract.

How Guardr fits

Guardr is a self-serve security posture monitor built for web agencies and developers managing multiple sites.

It covers everything above plus uptime monitoring, and includes platform-specific fix instructions per finding — the exact Cloudflare, Nginx, or Apache config snippet, not just a description of the problem.

Feature	Hardenize	Guardr
Security header monitoring	✅	✅
TLS / cert expiry alerts	✅	✅
DNS security checks	✅	✅
Cookie security	✅	✅
Exposure path detection	✅	✅
Uptime monitoring	❌	✅
Fix instructions per platform	❌	✅
Self-serve available	⛔ Gone	✅
Starting price	$5K+/year	$7/month

Letter grade, tracked over time

Every site gets an A–F grade based on its full security configuration — TLS, headers, DNS, cookies, and exposure paths. The grade is tracked over time so you can see when a deployment caused a regression, and alerts fire when it drops.

Free scanner — no login needed

You can scan any URL for free at guardr.io — no account required. You'll get a letter grade and full breakdown of every misconfiguration, with fix instructions included.

From there you can set up continuous monitoring with one click.

Full comparison at guardr.io/blog/vs-hardenize.

What Does a Website Security Score Mean?

Guardr — Sun, 15 Mar 2026 19:20:22 +0000

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.

How to Fix Missing HSTS Header (Step-by-Step)

Guardr — Wed, 11 Mar 2026 19:01:01 +0000

If you've scanned your website and received a warning about a missing HSTS header, you're not alone. From our internal checks, most of the none technical websites are misconfigured and are missing HSTS header mostly because they are lack of security awareness, this is why we want to raise such awareness. It's one of the most common security findings and one of the most impactful to fix. This guide walks you through what HSTS is, why your site needs it, and how to enable it on every major platform.

What's covered

What is HSTS and why does it matter?
How HSTS protects your users
Before you enable HSTS
How to add HSTS on Cloudflare
How to add HSTS on Nginx
How to add HSTS on Apache
How to add HSTS on other platforms
Understanding the HSTS directives
Common mistakes when enabling HSTS
HSTS preloading explained
How to verify HSTS is working

What is HSTS and why does it matter?

HSTS stands for HTTP Strict Transport Security. It's a security header that tells browsers: "Only connect to this site over HTTPS. Never use HTTP."

Without HSTS, here's what can happen. A user types yoursite.com into their browser. The browser first tries http://yoursite.com. Your server redirects to https://yoursite.com. That initial HTTP request — before the redirect — is unencrypted and vulnerable. An attacker on the same network (coffee shop Wi-Fi, hotel network, airport) can intercept that first request, steal cookies, inject malicious content, or redirect the user to a fake version of your site. This is called a protocol downgrade attack.

HSTS eliminates this window of vulnerability. Once a browser sees the HSTS header, it remembers: "This site is HTTPS-only." Every future visit goes directly to HTTPS — no HTTP request, no redirect, no attack window.

This isn't a theoretical risk. SSL stripping attacks are well-documented and tools to execute them are freely available. If your site handles any user data — logins, forms, personal information, payments — HSTS should be considered essential.

How HSTS protects your users

HSTS provides three specific protections:

No protocol downgrade. Browsers refuse to connect over HTTP, even if the user types http:// explicitly or clicks an old HTTP link. The browser automatically upgrades to HTTPS before making the request.

No mixed content fallback. If any resource on your page tries to load over HTTP, the browser blocks or upgrades it. This prevents attackers from injecting content through insecure resource loads.

Cookie protection. Without HSTS, cookies set without the Secure flag could leak over an HTTP connection. HSTS ensures the connection is always encrypted, adding a layer of protection even if cookie flags aren't perfect.

Before you enable HSTS

HSTS is powerful, but it's also a commitment. Once a browser caches your HSTS policy, it will refuse to connect over HTTP until the max-age expires. If your HTTPS setup has problems, users won't see a warning — they'll see a hard error with no way to bypass it.

Before enabling HSTS, verify these things:

Your SSL/TLS certificate is valid and not expiring soon. All pages on your site load correctly over HTTPS. All resources (images, scripts, stylesheets, fonts) are served over HTTPS — no mixed content. If using includeSubDomains, every subdomain also works over HTTPS. Your HTTP-to-HTTPS redirect is working correctly (301 permanent redirect).

If any of these aren't ready, fix them first. Start with a short max-age (like 300 seconds / 5 minutes) to test safely. Once everything works, increase to the recommended value.

How to add HSTS on Cloudflare

Cloudflare offers two approaches.

Option 1: Cloudflare Dashboard (easiest)

Go to your Cloudflare dashboard, select your site, then navigate to SSL/TLS → Edge Certificates. Scroll down to find the HSTS setting and click "Enable HSTS." Cloudflare will show you a confirmation dialog explaining the implications. Configure it with max-age of 12 months, includeSubDomains on, and preload on.

Option 2: _headers file (for Cloudflare Pages)

If you're using Cloudflare Pages, create or edit a _headers file in your project's output directory:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The /* means this header applies to all pages. Deploy your site and the header will be served on every response.

How to add HSTS on Nginx

Add one line inside your server block for the HTTPS configuration:

server {
    listen 443 ssl http2;
    server_name example.com;

    # Add HSTS header
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # ... rest of your config
}

The always keyword is important — it ensures the header is sent even on error responses (4xx, 5xx). Without it, Nginx only adds the header on successful responses.

Make sure you only add HSTS to your HTTPS server block, not the HTTP one. The HTTP block should only contain the redirect to HTTPS:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

After editing, test and reload:

nginx -t
systemctl reload nginx

How to add HSTS on Apache

Enable the headers module if it isn't already, then add the header in your VirtualHost configuration or .htaccess file:

# Enable module (if not already)
# a2enmod headers

<VirtualHost *:443>
    ServerName example.com

    # Add HSTS header
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # ... rest of your config
</VirtualHost>

Or in .htaccess (if your host supports it):

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Restart Apache after changes:

systemctl restart apache2

How to add HSTS on other platforms

Vercel — add to vercel.json:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "Strict-Transport-Security",
          "value": "max-age=31536000; includeSubDomains; preload"
        }
      ]
    }
  ]
}

Netlify — add to _headers file or netlify.toml:

[[headers]]
  for = "/*"
  [headers.values]
    Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"

AWS CloudFront — use a Response Headers Policy in the CloudFront distribution settings. Navigate to Policies → Response headers → Create policy → Security headers → Enable Strict-Transport-Security.

WordPress — if you can't edit server config, use a security plugin like "HTTP Headers" or "Really Simple SSL" which can add HSTS through PHP. However, server-level configuration is always preferred.

Understanding the HSTS directives

The full recommended HSTS header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Each part serves a specific purpose:

max-age=31536000 tells the browser how long to remember the HSTS policy, in seconds. 31536000 seconds equals one year. During this time, the browser will never attempt an HTTP connection. The timer resets on every visit, so regular visitors stay protected indefinitely. For initial testing, use max-age=300 (5 minutes). Once confirmed working, increase to a full year.

includeSubDomains extends the policy to every subdomain under your domain. If you set HSTS on example.com with includeSubDomains, then api.example.com, blog.example.com, and staging.example.com are all forced to HTTPS as well. Only add this if every subdomain supports HTTPS. One subdomain without a valid certificate will become completely inaccessible.

preload signals that you want your domain added to browser HSTS preload lists. These are lists compiled into Chrome, Firefox, Safari, and Edge that force HTTPS from the very first visit — not just after the browser first sees your header. To actually get preloaded, you need to submit your domain at hstspreload.org after adding the header.

Common mistakes when enabling HSTS

Setting max-age too high on the first try. If you discover a problem after setting a one-year max-age, visitors' browsers will refuse HTTP connections for up to a year. Start with 5 minutes, then 1 day, then 1 week, then 1 year.

Adding includeSubDomains when subdomains aren't ready. If staging.example.com runs on HTTP or has an expired certificate, it becomes unreachable. Audit all subdomains first.

Only adding HSTS to some pages. HSTS should be on every response from your domain. Use the wildcard path (/* in Cloudflare/Netlify) or add it at the server level in Nginx/Apache.

Adding HSTS to HTTP responses. The header should only be served over HTTPS. Browsers ignore HSTS headers received over HTTP (for good reason — an attacker could inject a fake one). Your HTTP server block should only redirect to HTTPS.

Forgetting about cookies. HSTS protects the transport layer, but you should also set the Secure flag on all cookies to ensure they're never sent over HTTP. HSTS and Secure cookies work together.

HSTS preloading explained

The HSTS preload list is a registry of domains that browsers treat as HTTPS-only from the very first connection. Without preloading, a user's first visit is still vulnerable because the browser hasn't seen your HSTS header yet. Preloading eliminates this gap.

To qualify for preloading, your site must serve a valid HSTS header with max-age of at least one year (31536000), include the includeSubDomains directive, include the preload directive, and redirect all HTTP traffic to HTTPS.

Submit your domain at hstspreload.org after meeting these requirements. The submission is reviewed and, once accepted, your domain is hardcoded into browser source code. This process takes weeks to months — browsers need to ship updates that include the new list.

A warning: removing your domain from the preload list is difficult and slow. Only preload domains you're certain will stay on HTTPS permanently.

How to verify HSTS is working

After deploying, verify with any of these methods:

Using curl:

curl -I https://yoursite.com

Look for Strict-Transport-Security in the response headers. You should see your full policy with max-age, includeSubDomains, and preload.

Using browser DevTools:

Open your site in Chrome or Firefox, press F12, go to the Network tab, click the first request (your domain), and check the Response Headers section.

Using Guardr:

Scan your site for free — Guardr checks your HSTS configuration and tells you exactly what's missing or misconfigured. If your HSTS is working correctly, the TLS/SSL score reflects it. If something is off — missing includeSubDomains, short max-age, or HSTS not present at all — you'll see a specific finding with the exact fix.

HSTS is one of the highest-impact security improvements you can make. It takes one line of configuration, costs nothing, and protects every user on every visit. If your site is served over HTTPS (and it should be), there's no reason not to enable it.

Start with a short max-age, verify everything works, then commit to a full year. Your users and your security score will thank you.