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.
84.7% of .com domains have this exact gap. Only 15.3% have it in place.
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 →Watch this check turn green.
A one-line header that stops browsers from guessing what a file 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 to hijack logged-in sessions or steal card-entry and login details. That can turn into a data breach. It is one of the cheapest fixes in security: one line, free, about five minutes.
82.2% of .com domains have this exact gap. Only 17.8% have it in place.
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 →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 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. Regulators treat that as a data-protection problem, and it breaks your own privacy promise. It is also a graded gap that a client's security team will flag during due diligence.
92.1% of .com domains have this exact gap. Only 7.9% have it in place.
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
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 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. 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.
78.9% of .com domains have this exact gap. Only 21.1% have it in place.
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
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 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 run a padlocked copy of your site to harvest your customers' logins and card details, with nothing on screen to warn them.
98.6% of .com domains have this exact gap. Only 1.4% have it in place.
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:security@example.com"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:security@example.com"
dig CAA example.com +short shows your records → re-check.
Re-scan example.com →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://'.
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 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 →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 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.
89.9% of .com domains have this exact gap. Only 10.1% have it in place.
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 →Watch this check turn green.
DMARC can ask the world's mail providers to send you a regular summary of every message they received claiming to come from your domain: which servers sent it, and whether it passed SPF and DKIM. That request is the rua= tag in your DMARC record, and your record does not include it, so no reports are sent to you.
You cannot see who is sending email as your business. If a legitimate tool you rely on (an invoicing system, a newsletter platform, a new email provider) starts failing authentication, receivers can quarantine or reject its mail under your policy and nothing tells you. The same blind spot hides anyone trying to impersonate you.
90.2% of .com domains have this exact gap. Only 9.8% have it in place.
WhereAdd a rua= tag to your existing DMARC record. Update the TXT record at _dmarc.example.com to include: rua=mailto:dmarc@example.com Full record example: v=DMARC1; p=reject; rua=mailto:dmarc@example.com 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 →Watch this check turn green.