A one-line instruction that tells browsers not to let other websites secretly load your site inside their own. Without it, a scammer can hide your real, logged-in pages behind a fake page and trick your customers into clicking things they never meant to — approving a payment, changing a password, granting access.
A fraudster can invisibly wrap your live website inside a fake one and steal money or account access from your logged-in customers — and to the customer it looks like your site did it. The fix is free and takes a developer about 15 minutes; leaving it off is a known gap that both criminals and cautious buyers can spot in seconds.
94.3% of .com domains have this exact gap. Only 5.7% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour web server / CDN response headers
X-Frame-Options: SAMEORIGIN
(its own header — if you'd rather use CSP, add frame-ancestors 'self' to the Content-Security-Policy step instead of setting a second CSP header)If you need to undo itDelete the header. If your site is embedded elsewhere on purpose, list those origins instead of self.
curl -sI https://example.com | grep -i x-frame-options x-frame-options: SAMEORIGIN
Re-check — the frame/clickjacking check passes.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
A one-line header that stops browsers from guessing what a file really is. Without it, a file someone uploads to your site — or a file on your own pages — can be mis-read by the browser and run as code, which is exactly how some attacks turn a harmless-looking upload into a way to steal your customers' sessions.
Missing this header is a clear, scannable sign that the basics aren't in place. On its own it rarely takes a site down, but combined with a file-upload form or user-generated content it opens a path for an attacker to run malicious code in your visitors' browsers — hijacking logged-in sessions, stealing card-entry or login details, and putting you on the wrong side of a data-breach conversation. It is one of the cheapest fixes in security: one line, free, about five minutes.
92.7% of .com domains have this exact gap. Only 7.3% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour web server / CDN response headers (Cloudflare: Rules → Transform Rules → Modify Response Header)
X-Content-Type-Options: nosniffIf you need to undo itDelete the header rule. Nothing depends on it.
curl -sI https://example.com | grep -i x-content-type-options x-content-type-options: nosniff
Re-check — the x-content-type-options check flips to pass.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
A Referrer-Policy is a one-line instruction your website hands to every visitor's browser, controlling how much of your web address travels with them when they click a link to another site. Without it, the full address of whatever page they were on — search terms, account numbers, reset links, internal page paths and all — is quietly handed to the next site they land on, including advertisers, analytics firms, and anywhere else a link points.
Every time a visitor clicks an outbound link, ad, or shared resource, their browser can hand the full address of your page to the destination — and if your addresses carry search queries, customer IDs, order numbers, or one-time links, you are leaking customer data to third parties you do not control. That is a data-protection problem regulators take seriously, a privacy promise quietly broken, and a graded gap a client's security team will flag during due diligence.
97% of .com domains have this exact gap. Only 3% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour web server / CDN response headers
Referrer-Policy: strict-origin-when-cross-originIf you need to undo itDelete the header rule.
curl -sI https://example.com | grep -i referrer-policy referrer-policy: strict-origin-when-cross-origin
Re-check — referrer-policy passes.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
HSTS is a one-line instruction your website gives every browser: 'always come back to me over the secure, encrypted connection — never the insecure one.' Without it, your padlock can be quietly stripped away on shared WiFi, and the very first visit to your site is exposed.
Having HTTPS (the padlock) is not the same as enforcing it. Without HSTS, an attacker on the same WiFi as your customer can silently downgrade the connection to plain, unencrypted HTTP — capturing logins, card details and form data while the customer sees nothing wrong. Your SSL certificate, which you may be paying for, is bypassed. The fix is free and takes about 15 minutes for whoever runs your site.
80.9% of .com domains have this exact gap. Only 19.1% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour web server / CDN response headers
Strict-Transport-Security: max-age=31536000; includeSubDomainsIf you need to undo itLower max-age to 0 and wait out the old value before removing.
curl -sI https://example.com | grep -i strict-transport strict-transport-security: max-age=31536000; includeSubDomains
Re-check — hsts-header passes.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
A CAA record is a short instruction in your domain settings that names which certificate companies are allowed to issue the 'padlock' security certificate for your website. With it switched on, no other company can quietly create a valid certificate in your name.
Without a CAA record, almost any of the hundreds of certificate companies worldwide can issue a genuine, fully-trusted padlock certificate for your domain — letting a scammer stand up a flawless, fully 'secure'-looking clone of your site to harvest your customers' logins and card details, with nothing on screen to warn them.
98.5% of .com domains have this exact gap. Only 1.5% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour DNS host — add CAA records on example.com
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 iodef "mailto:[email protected]"If you need to undo itDelete the CAA records (prior state was "any CA may issue").
dig CAA example.com +short 0 issue "letsencrypt.org" 0 issue "pki.goog" 0 iodef "mailto:[email protected]"
dig CAA example.com +short shows your records → re-check.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
HTTPS is the padlock in the browser bar — it encrypts everything that travels between your website and your customers so it can't be read or tampered with in transit. The forced-secure redirect makes sure visitors land on that encrypted version automatically, even when they type your address without 'https://'. Together they are the single most basic thing a website needs to be considered safe at all.
Without HTTPS, every password, card number and message a customer sends you crosses the internet as readable text, and Chrome, Edge, Safari and Firefox all stamp your site 'Not secure' for every visitor before they read a word. Without the redirect, even sites that have a certificate leave the very first visit unprotected. Both cost you trust, sales and search ranking — and both are free to fix in minutes.
WhereAdd a redirect from HTTP to HTTPS: Nginx: server { listen 80; server_name example.com; return 301 https://$host$request_uri; } Apache (.htaccess): RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Cloudflare: SSL/TLS > Edge Certificates > Always Use HTTPS = On IIS: Install URL Rewrite module and add HTTP to HTTPS redirect rule
Re-check http-to-https-redirect after applying the fix.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
A Content Security Policy is a safety rule your website hands to every visitor's browser, telling it exactly which code is allowed to run. Without one, if anything malicious ever lands on a page — through a comment box, a hacked plugin, or a third-party script — the browser will run it freely, including code that quietly skims your customers' card numbers and passwords as they type, with the padlock still showing.
If your site is ever tampered with, malicious code can read your customers' payment-card and login details straight off your own checkout while everything looks completely normal — leaving you with chargebacks, fraud claims, a reportable data breach, and a check failure that larger clients' security teams use to stall or kill a deal.
96.2% of .com domains have this exact gap. Only 3.8% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereYour web server / CDN response headers
Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self'; script-src 'self'; frame-ancestors 'self'If you need to undo itSwitch back to -Report-Only, or remove the header.
curl -sI https://example.com | grep -i content-security-policy content-security-policy: default-src 'self'; ...; frame-ancestors 'self'
Re-check — csp-header passes (report-only still counts as present; tighten toward enforce).
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
DMARC is the one setting that actually tells the world's mail providers to BLOCK emails that fake your business's name. SPF and DKIM check the locks; DMARC decides what happens when a forgery fails the check — bin it, flag it, or wave it through. Set wrong, your domain is fully forgeable; set right, impersonation stops at the inbox.
Without DMARC enforcement, a criminal can send email that looks exactly like it came from your business — to your customers, staff and suppliers — and it lands in their inbox, not their spam. People get scammed in your name, and they blame you.
89.8% of .com domains have this exact gap. Only 10.2% have it in place.
You are fixing something most of your peers have not — and it is measured the same way for every one of them.
WhereAdd a rua= tag to your existing DMARC record. Update the TXT record at _dmarc.example.com to include: rua=mailto:[email protected] Full record example: v=DMARC1; p=reject; rua=mailto:[email protected] Alternatively, use a free DMARC reporting service like dmarcian.com or postmarkapp.com/dmarc for easier report analysis.
Re-check dmarc-reporting after applying the fix.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.
YOUR business emails are likely being silently REJECTED or sent to spam folders across the internet right now. Major email providers including Gmail, Microsoft 365, and Yahoo actively check reverse DNS on the SENDING mail server — and when it fails, your emails get flagged as suspicious. That means your invoices, proposals, and customer communications are disappearing into spam. You're losing deals and damaging relationships without even knowing it. Every email provider on the planet uses PTR records as a trust signal.
WhereThe primary MX server () could not be resolved. This is likely a managed email provider issue — contact your email provider.
Re-check reverse-dns after applying the fix.
Re-scan example.com →Runs the same engine that graded every domain in the census. Watch this check turn green.