DEV Community: Håkan Fägnell

X-Frame-Options: How It Works and How to Set It | FortifyNet

Håkan Fägnell — Wed, 19 Aug 2026 04:45:29 +0000

X-Frame-Options: What It Does and How to Configure It Right

X-Frame-Options is an HTTP response header that tells the browser whether your page may be rendered inside a frame or iframe on another site. It has exactly two valid values: DENY (no framing at all) and SAMEORIGIN (framing allowed only from your own origin). Its purpose is to stop clickjacking, an attack where your site is loaded invisibly inside an attacker's page and your visitors are tricked into clicking things they cannot see. The modern replacement is the Content-Security-Policy directive frame-ancestors, and the 2026 best practice is to send both headers. This guide covers the correct setup for every major server, plus the mistakes that silently disable the protection.

What the X-Frame-Options header does

When a browser loads a page that another document has embedded through <iframe>, <frame>, <embed> or <object>, it checks the response headers of the embedded page before rendering it. If the response carries X-Frame-Options: DENY, the browser refuses to draw the page inside the embedding document. With SAMEORIGIN, it renders the page only if the embedding chain comes from the same origin (same scheme, host and port). Modern browsers evaluate the entire chain of ancestor frames, not just the top window.

The header was formalized in RFC 7034 in October 2013, after browsers had already shipped it. It remains one of the most widely deployed security headers: the HTTP Archive Web Almanac 2025 security chapter measures X-Frame-Options on roughly 35% of mobile sites, making it a top three security header behind X-Content-Type-Options (close to 50%).

Clickjacking in 60 seconds

Clickjacking was named by security researchers Robert Hansen and Jeremiah Grossman in 2008. The attack is simple: an attacker's page loads your site in an iframe, makes the iframe fully transparent with CSS, and positions it over harmless looking buttons. The visitor believes they are clicking "Play video", but the click actually lands on your site's "Delete account", "Confirm payment" or "Authorize app" button, using the victim's logged-in session. OWASP documents variants ranging from Facebook "likejacking" to hijacked one-click purchases.

Framing control is the defense. If the browser refuses to render your page inside an attacker's frame, the overlay trick collapses.

The two valid values, and the ones to avoid

Value	Effect	Status in 2026
`DENY`	No site may frame the page, including your own	Valid, supported by all browsers
`SAMEORIGIN`	Only pages from the same origin may frame it	Valid, supported by all browsers
`ALLOW-FROM uri`	Was meant to allow one named origin	Obsolete: Firefox removed it in version 70 (October 2019), Chrome and Safari never supported it
`ALLOWALL`	Never part of any spec	Invalid: browsers ignore the header entirely, leaving no protection

The dangerous part is how browsers handle invalid values: they ignore the whole header. A site sending ALLOW-FROM or ALLOWALL believes it is protected while browsers treat it as if no header were set. As the Web Almanac 2025 puts it, these values "may have been set by developers expecting protections to be active due to them setting the header."

What real-world data shows

Across millions of sites measured by HTTP Archive in 2025, the header's values break down like this:

Source: HTTP Archive Web Almanac 2025, security chapter, figure 9.30 (mobile dataset).

About 72.1% of sites that send the header choose SAMEORIGIN and 24.6% choose DENY. Roughly 3% send values that do nothing, which on the scale of the web is hundreds of thousands of sites with imaginary protection. Checking what your server actually sends takes less than a minute.

X-Frame-Options vs CSP frame-ancestors

The W3C Content Security Policy Level 2 specification (a W3C Recommendation since December 2016) introduced the frame-ancestors directive and formally obsoleted X-Frame-Options. Where XFO is a blunt on/off switch, frame-ancestors is a full allowlist:

Capability	X-Frame-Options	CSP frame-ancestors
Block all framing	`DENY`	`frame-ancestors 'none'`
Allow own origin only	`SAMEORIGIN`	`frame-ancestors 'self'`
Allow named partner origins	Not possible (ALLOW-FROM is dead)	`frame-ancestors 'self' https://partner.example.com`
Wildcard subdomains	Not possible	`frame-ancestors https://*.example.com`
Spec status	Informational RFC 7034 (2013), obsoleted	W3C CSP Level 2 (2016), current standard
When both headers are present	Ignored by CSP2-capable browsers	Takes precedence

Two details worth knowing. First, MDN notes that frame-ancestors does not inherit from default-src: a policy of default-src 'none' still allows anyone to frame the page, so you must declare the directive explicitly. Second, all current versions of Chrome, Edge, Firefox and Safari support frame-ancestors, so the only reason to keep sending X-Frame-Options is defense in depth for very old clients. That costs one line, so keep it.

How to configure it on your server

Send the header on every HTML response, exactly once. The examples below set SAMEORIGIN plus the equivalent CSP directive.

nginx (inside server or location):

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache 2.4 (httpd.conf or .htaccess, mod_headers enabled):

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

IIS (web.config):

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Content-Security-Policy" value="frame-ancestors 'self';" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Node.js with Express and Helmet:

const helmet = require("helmet");
app.use(helmet.frameguard({ action: "sameorigin" }));
app.use(helmet.contentSecurityPolicy({
  directives: { frameAncestors: ["'self'"] }
}));

Behind a CDN such as Cloudflare you can also inject both headers with a response header transform rule, which is useful when you cannot touch the origin server. If a partner site legitimately needs to embed you, keep XFO at SAMEORIGIN and express the allowlist in CSP: frame-ancestors 'self' https://partner.example.com.

Mistakes that silently disable the protection

Using ALLOW-FROM in 2026. Every current browser ignores it, and with it the whole header.
Setting the header in a meta tag. X-Frame-Options only works as an HTTP header, and frame-ancestors is explicitly forbidden inside <meta http-equiv="Content-Security-Policy">. Both must come from the server.
Sending the header twice. Duplicate or comma-joined values such as SAMEORIGIN, SAMEORIGIN (0.28% of sites in the Almanac 2025 data) can be rejected as invalid. Set it in one place only, either the app or the web server, not both.
Using DENY on pages you embed yourself. If your own checkout, widget or preview runs in an iframe, DENY breaks it. Use SAMEORIGIN or an explicit frame-ancestors allowlist.
Assuming default-src covers framing. It does not. Declare frame-ancestors explicitly.

How to test your configuration

Open your browser's developer tools, load your page, and inspect the response headers on the main document: you should see exactly one X-Frame-Options and a Content-Security-Policy containing frame-ancestors. For the full picture, the free FortifyNet scan checks your framing protection together with the rest of your security header set, SSL/TLS, DNS and email authentication in about 60 seconds, and tells you exactly which header to add where. No signup needed.

Related guides

FAQ

Is X-Frame-Options deprecated?
Formally yes: W3C CSP Level 2 obsoleted it in favor of frame-ancestors back in 2016. In practice every browser still honors it, and OWASP recommends sending both headers for defense in depth. The one thing you must not do is rely on ALLOW-FROM.

Should I use DENY or SAMEORIGIN?
Use DENY if nothing on your site is ever shown in a frame, which is the strongest setting. Use SAMEORIGIN if your own pages embed each other, for example dashboards, previews or internal widgets. In the 2025 Web Almanac data, 72.1% of sites choose SAMEORIGIN.

How do I allow one specific partner site to embed my pages?
X-Frame-Options cannot do this anymore. Use Content-Security-Policy: frame-ancestors 'self' https://partner.example.com and list each allowed origin explicitly.

What happens if I send both X-Frame-Options and frame-ancestors?
Browsers that support CSP Level 2, which is all modern ones, enforce frame-ancestors and ignore X-Frame-Options. Older clients fall back to X-Frame-Options. That fallback chain is exactly why sending both is the recommended setup.

Can I set X-Frame-Options with a meta tag?
No. Browsers only honor it as a real HTTP response header. If you cannot change server configuration, set it through your hosting panel, CDN rules or application middleware.

Originally published at fortifynet.com/blog/x-frame-options. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

ERR_CERT_AUTHORITY_INVALID: Causes and Fixes | FortifyNet

Håkan Fägnell — Mon, 17 Aug 2026 04:45:29 +0000

ERR_CERT_AUTHORITY_INVALID means the browser could not build a chain of trust from the certificate your server presented back to a root certificate authority it already trusts. Chrome shows it as NET::ERR_CERT_AUTHORITY_INVALID under a "Your connection is not private" screen. It is almost never a sign that your certificate has expired, and almost always one of two things: your server is not sending its intermediate certificate, or the certificate was not issued by a publicly trusted CA at all. The fix takes minutes once you know which side the fault is on.

What the error actually means

Every TLS certificate is validated by walking a chain. The browser receives your server (leaf) certificate, reads which CA signed it, and looks for that CA. If the signing CA is an intermediate, the browser needs that intermediate certificate too, so it can check who signed that, and keep walking until it reaches a root certificate that is already installed in its trust store.

If any link in that walk is missing, unsigned by a trusted party, or issued by a CA the browser has removed, the chain cannot be completed and the connection is refused with ERR_CERT_AUTHORITY_INVALID.

Chrome ships its own trust list, the Chrome Root Store, rather than relying only on the operating system. Firefox does the same. Safari and Edge lean on the OS store. That difference is why a site can fail in one browser and load in another on the same machine, and it is one of the most useful diagnostic signals you have.

The seven causes, and where the fault lies

#	Cause	Fault is on	Typical tell
1	Missing intermediate certificate in the server chain	Server	Fails on mobile and fresh devices, loads on your own desktop
2	Self-signed certificate	Server	Internal tools, staging, NAS boxes, routers, printers
3	Certificate from a private or internal CA	Server	Works on corporate laptops only
4	TLS interception by antivirus or a corporate proxy	Device / network	Every HTTPS site fails, issuer name is your AV vendor
5	Outdated device root store (old Android, old Windows)	Device	Only that one device fails
6	System clock badly wrong	Device	Root itself appears not yet valid or long expired
7	The issuing CA has been distrusted or removed	Server	Fails in Chrome, still fine in an older browser

Causes 1 and 2 account for the overwhelming majority of real reports. If you own the site, start there.

The 30-second triage

Before changing anything, work out whether the problem lives on the server or on the visitor's machine.

Open the site on mobile data, on a phone that has never visited it. If it fails there but works on your desktop, you have a missing intermediate. Desktop browsers cache intermediates they have seen before and can silently repair a broken chain, which is exactly why this bug survives so long undetected.
Try a second browser on the same machine. Failing in Chrome only points at the Chrome Root Store rejecting the CA. Failing everywhere on one machine points at interception or an outdated device.
Click the warning, then "Advanced", and read the issuer. If the issuer is your antivirus product, a firewall vendor, or your employer's name, traffic is being intercepted and re-signed. That is cause 4, and it is not your website's fault.
Check the chain from the command line with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com -showcerts

You should see at least two certificates in the output: your leaf, then one or more intermediates. If only one certificate comes back, the intermediate is missing and you have found the bug.

Fix 1: install the full certificate chain

This is the single most common server-side cause. Your CA issues you a leaf certificate and one or more intermediates, and your server has to send all of them. Point your web server at the full chain file rather than the leaf alone.

Server	What to configure
nginx	`ssl_certificate` must point at `fullchain.pem` (leaf + intermediates concatenated), not `cert.pem`
Apache 2.4.8+	Concatenate leaf and intermediates into the file used by `SSLCertificateFile`; `SSLCertificateChainFile` is deprecated
IIS	Import the intermediate into the Intermediate Certification Authorities store on the machine account
Caddy / Traefik	Handled automatically when using built-in ACME
Load balancer or CDN	The chain must be uploaded at the edge, not only on the origin

If you use Let's Encrypt, the fix is usually a one-word change: use fullchain.pem, never cert.pem. Let's Encrypt notes that every certificate it issues has an intermediate directly signed by its most widely trusted root, and that multiple active intermediates rotate over time, so hard-coding a specific intermediate file is fragile (Let's Encrypt, Chains of Trust). Reload the server after the change; a config change alone does nothing until the process picks it up.

Fix 2: replace a self-signed certificate

A self-signed certificate signs itself. No public CA vouches for it, so no browser can ever trust it without manual intervention. This is correct behaviour, not a bug.

For anything public-facing, get a free certificate from a publicly trusted CA and automate renewal. For genuinely internal tools, either add your internal root to the trust stores of the devices that need it, or issue from an internal CA that is already distributed by your device management. Do not train your team to click through the warning; that habit is precisely what phishing operators rely on.

Fix 3: rule out interception and stale devices

If the issuer shown in the warning is an antivirus product, temporarily disable its HTTPS or SSL scanning feature and reload. Many security suites insert their own root to inspect encrypted traffic, and a broken or expired inspection root breaks every HTTPS site at once.

On an outdated device, install pending OS updates. Root stores ship with system updates, and a device several years behind will be missing newer roots entirely. Finally, confirm the clock: a system date that is wildly wrong can make a valid root look not-yet-valid, which surfaces as an authority error rather than a date error.

Fix 4: check whether your CA is still trusted

Root programs remove CAs that fail their requirements, and those removals are real events with real deadlines. The Chrome Root Program requires that from 15 June 2026, newly issued public TLS certificates carry only the serverAuth extended key usage; certificates that also carry clientAuth will no longer be trusted by Chrome, and CA owners whose hierarchies do not comply must restructure or exit the store (Chrome Root Program Policy).

If a site suddenly fails in Chrome while older clients still accept it, a distrust event is a realistic explanation. The remedy is to reissue from a compliant CA.

Why this error is about to get more common

Certificate lifetimes are collapsing. Under CA/Browser Forum ballot SC-081v3, adopted in April 2025, the maximum validity period steps down from 398 days to 200 days on 15 March 2026, to 100 days in 2027, and to 47 days in 2029 (CA/Browser Forum, Ballot SC-081v3).

Maximum TLS certificate lifetime under CA/Browser Forum ballot SC-081v3. Source: CA/Browser Forum, April 2025.

More renewals mean more chances for an automation script to deploy a leaf without its intermediate. Every renewal is now a deployment, and every deployment can break the chain. Teams that renewed manually once a year and never thought about it again will hit this error for the first time in 2026.

Verifying the fix

After changing the chain, do not trust your own browser. It has cached the intermediate and will show you a green padlock over a chain that still fails for everyone else. Verify from a clean vantage point: an external scanner, a phone on mobile data, or a fresh browser profile. Confirm that the leaf and every intermediate are being served, and that no intermediate is itself expired.

Related guides

"Your connection is not private": what it means and how to fix it covers the wider warning screen this error appears under.
ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it handles the handshake-level failures that look similar but have different causes.
SSL/TLS certificate security: the complete guide to an A+ rating walks through chain, protocol and cipher configuration end to end.

FAQ

Is ERR_CERT_AUTHORITY_INVALID dangerous for visitors?
It can be. The browser is telling you it cannot verify who it is talking to, which is exactly the condition a machine-in-the-middle attack creates. On a site you do not control, treat the warning as real and do not proceed.

Why does the site work on my computer but not for my customers?
Desktop browsers cache intermediate certificates from previous visits and can complete a broken chain from memory. Devices that have never seen the intermediate cannot. This asymmetry is the classic signature of a missing intermediate.

Does clearing the browser cache fix it?
Rarely, and only when the fault is on the device. If the chain is broken on the server, clearing the cache changes nothing for anyone.

How is it different from ERR_CERT_COMMON_NAME_INVALID?
AUTHORITY_INVALID means the issuer cannot be trusted. COMMON_NAME_INVALID means the issuer is trusted but the certificate was issued for a different hostname than the one being visited.

Can I just click through the warning?
On your own staging server, yes. On any site handling real data, no. Clicking through disables the exact protection that would tell you the connection had been tampered with.

Check your chain before your visitors do

A missing intermediate is invisible from your own desk and obvious to every new visitor. Run a free FortifyNet scan and see your full certificate chain, protocol support, security headers, DNS and email authentication in about 60 seconds. No signup required.

Sources: CA/Browser Forum, Ballot SC-081v3; Chrome Root Program Policy; Let's Encrypt, Chains of Trust.

Originally published at fortifynet.com/blog/err-cert-authority-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

Pingdom Alternative: 7 Best Options in 2026 | FortifyNet

Håkan Fägnell — Thu, 13 Aug 2026 04:45:29 +0000

The best Pingdom alternative in 2026 depends on why you are switching. If the bill is the problem, UptimeRobot watches 50 URLs for free every 5 minutes, and its Solo plan costs $9/month against Pingdom's $10/month entry tier with just 10 uptime checks (UptimeRobot and Pingdom pricing pages, August 2026). If you can run a Docker container, Uptime Kuma is free, self-hosted and past 88,000 GitHub stars. And if what you really need to know is not just whether your site is down but why, FortifyNet audits SSL/TLS, DNS, email authentication and security headers in one free 60-second scan.

Below is an honest comparison of seven options, with prices and limits taken from each vendor's own pricing page in August 2026.

Why people look for a Pingdom alternative

Pingdom, owned by SolarWinds, is still a polished product. Three things send people looking elsewhere.

There is no free tier. Pingdom offers a trial, and after that the cheapest synthetic monitoring plan is $10/month billed annually, which includes 10 uptime checks, 1 advanced transaction check and 50 SMS alerts (Pingdom synthetic pricing, August 2026). Several rivals give you more monitors for free than Pingdom includes on its entry plan.

Costs climb with check count. Plans scale to roughly $249/month as uptime checks, transaction checks and SMS allowances grow. If you watch dozens of client sites, per-check pricing adds up faster than flat tiers like StatusCake's 100-monitor entry plan.

Alerting depth sits in higher tiers. On-call schedules, escalation chains and incident timelines largely live upmarket or in separate SolarWinds products, while newer tools such as Better Stack bundle them from the first paid plan.

If what you actually monitor is page speed rather than availability, start with our GTmetrix alternatives comparison instead.

What actually matters in an uptime monitor

Downtime is expensive enough that the tooling decision deserves ten minutes of thought. In the Uptime Institute's Annual Outage Analysis 2025, 57% of operators said their most recent significant outage cost more than $100,000, and roughly one in five put it above $1 million (Uptime Institute). ITIC's 2024-2025 Hourly Cost of Downtime survey found 93% of enterprises put a single hour of downtime above $300,000. Four things to compare before the price:

Check interval. A 5-minute interval can miss a 4-minute outage entirely, and it sets your worst-case detection delay. Free tiers usually check every 3 to 5 minutes; paid tiers drop to 60 or even 30 seconds.

Alert routing. An alert nobody wakes up for is a report, not an alert. Look for phone-call escalation, on-call rotations and per-channel rules, not just email.

Status pages. A public status page deflects support tickets during an incident. Some tools include branded pages free; others sell them separately.

What ping checks cannot see. An uptime monitor confirms your homepage answers with HTTP 200. It will happily report "up" while your TLS certificate is a day from expiring, your SPF record breaks email delivery, or your domain shows up in a credential dump. Availability and health are different questions.

The 7 best Pingdom alternatives compared

Tool	Free tier	Paid from (annual)	Fastest check (paid)	Standout feature
UptimeRobot	50 monitors, 5-min (non-commercial)	$9/mo	15 s	Most generous free allowance
Better Stack	10 monitors, 3-min	$29/mo	30 s	On-call and incident management built in
StatusCake	Yes, basic	$20.41/mo	1 min (30 s on Business)	100 monitors on the entry plan
Site24x7	5 basic monitors	$9/mo	1 min	Full infrastructure suite (Zoho)
Uptime Kuma	Free, self-hosted	$0 + your server	Configurable	90+ notification channels
Pulsetic	10 monitors, 5-min	$9/mo	30 s (Team, $19/mo)	Cheapest route to 30-second checks
FortifyNet	Full 60-second audit	Freemium	Audit, not ping	Finds the failures ping checks miss
Pingdom (reference)	None, trial only	$10/mo	1 min	Established synthetic suite

Sources: vendor pricing pages, August 2026. Entry prices are annual-billing rates and change; check the vendor page before buying.

1. UptimeRobot, the default budget pick

The free plan monitors 50 URLs at 5-minute intervals, which is the most generous free allowance in this list, though since October 2024 it is limited to personal, non-commercial use (UptimeRobot pricing). The Solo plan at $9/month billed annually unlocks 60-second checks and commercial use; Team is $38/month and Enterprise starts at $69/month, with login seats billed extra on the two higher tiers.

Best for: solo builders, side projects and small businesses replacing Pingdom's entry plan at a lower price.

2. Better Stack, monitoring plus incident management

Better Stack bundles what Pingdom sells piecemeal: uptime checks, a status page, on-call scheduling, escalation policies and incident timelines. The free tier includes 10 monitors at 3-minute intervals with 1 phone-call alert; paid starts at $29/month with 30-second checks (Better Stack pricing, August 2026).

Best for: teams that would otherwise buy an uptime monitor and a separate incident-management tool.

3. StatusCake, most monitors per dollar

StatusCake keeps a basic free tier, and its entry paid plan at $20.41/month includes 100 uptime monitors at 1-minute intervals plus page speed, domain and SSL expiry monitoring (StatusCake pricing, August 2026). The Business plan at $66.66/month raises that to 300 monitors at 30-second intervals.

Best for: agencies and freelancers watching many small client sites on one bill.

4. Site24x7, the all-in-one suite

Site24x7, part of the Zoho family, folds uptime monitoring into a wider platform covering servers, applications, logs and networks. There is a free plan for up to 5 basic monitors, and the Starter plan begins at $9/month (Site24x7 pricing, August 2026).

Best for: teams that want website, server and application monitoring on a single invoice.

5. Uptime Kuma, self-hosted and free

Uptime Kuma is the open-source favourite, past 88,000 GitHub stars by mid-2026 (GitHub). Version 2.0 (October 2025) added MariaDB support and rootless Docker images; version 2.1 (February 2026) added Globalping-powered worldwide probes and domain expiry monitoring. It checks HTTP(S), TCP, DNS, ping, Docker containers and SSL certificate expiry, and alerts through more than 90 notification channels.

The cost is your own server and your own maintenance, and there is no SLA. One caution: host it on infrastructure separate from what it watches, or an outage takes the watchman down with the site.

Best for: homelabs and technical teams comfortable operating their own tooling.

6. Pulsetic, the reader-suggested addition

Pulsetic joined this list after a reader suggested it in the comments, and its pricing holds up against the rest of the field. The free tier covers 10 monitors at 5-minute intervals, the Solo plan at $9/month moves to 60-second checks, and 30-second checks start on the Team plan at $19/month (Pulsetic pricing, checked 18 August 2026). Going by the plans in this comparison, that Team tier is the cheapest route to 30-second checks here.

Best for: budget users who want 60-second checks at entry-level pricing, with an affordable 30-second upgrade path.

7. FortifyNet, because "up" is not the same as "healthy"

FortifyNet is not a ping-based uptime monitor, and it does not pretend to be. It answers the question uptime tools skip: is the site that just answered HTTP 200 actually configured safely? The free 60-second scan checks SSL/TLS configuration, DNS records, email authentication (SPF, DKIM and DMARC), HTTP security headers, dark-web exposure for your domain and performance, then returns one prioritised list.

Pair it with any monitor above. The monitor tells you the moment the site goes down; FortifyNet finds the expired-certificate-in-three-days, missing-DMARC, leaked-credentials class of problem that never triggers a ping alert until it is too late.

Best for: site owners who want to catch quiet failures before customers, or attackers, notice.

Entry prices, side by side

Cheapest paid plan per tool, USD/month billed annually, August 2026. Uptime Kuma is open source, so the licence is free and you pay only for hosting. Pulsetic's Solo plan is also $9/month (not yet in the chart). Feature scope differs widely between these entry plans.

How to switch from Pingdom without missing an incident

Inventory your checks. List every uptime check, transaction check and integration you have in Pingdom, including the ones a colleague set up years ago.
Run both tools in parallel for two weeks. Set up the new monitor while Pingdom still runs. Two overlapping bills for two weeks is cheaper than one missed outage.
Match intervals and locations. A 60-second check from three regions is not comparable to a 5-minute check from one. Configure the new tool at least as tightly as the old one.
Rebuild alert routing before cosmetics. Escalation rules and phone alerts first, status page styling last.
Test the failure path deliberately. Take a staging endpoint down on purpose and confirm the right person's phone actually rings.
Cancel Pingdom only after a clean overlap. Export any uptime history you may need for SLA reporting first.

Which one should you pick?

Cheapest reliable monitoring for a few sites: UptimeRobot.
On-call scheduling and incident management included: Better Stack.
Many client sites on a budget: StatusCake.
Uptime plus servers, apps and logs in one place: Site24x7.
Full control and zero licence cost: Uptime Kuma.
Cheapest route to 30-second checks: Pulsetic.
Finding the problems a ping check cannot see: FortifyNet.

For most small businesses the practical answer is a pair: one ping monitor from the list above for the moment things break, and a recurring FortifyNet scan for the quiet failures in between.

FAQ

Is there a completely free Pingdom alternative?
Two kinds. UptimeRobot's free plan covers 50 monitors at 5-minute intervals but is limited to personal, non-commercial use since October 2024. Uptime Kuma is free and open source for any use, but you host and maintain it yourself.

Does Pingdom still have a free plan?
No. Pingdom offers a trial, after which synthetic monitoring starts at $10/month billed annually for 10 uptime checks and 1 advanced check (Pingdom pricing page, August 2026).

What check interval do I actually need?
Match it to the cost of an undetected minute. A personal blog is fine at 5 minutes. A checkout flow deserves 30 to 60 seconds, because the interval is your worst-case detection delay on top of alerting time.

Can an uptime monitor tell me why my site is down?
Only roughly. Most distinguish DNS failure, connection timeout and HTTP error codes, which narrows the search. For causes that build up silently, such as certificates about to expire, broken SPF or DMARC records, or missing security headers, run a FortifyNet scan and fix what it flags before it becomes downtime.

Is a self-hosted monitor like Uptime Kuma reliable enough for production?
Yes, with one rule: run it on infrastructure independent of what it monitors, ideally a different provider and region. You also own updates, backups and the notification configuration, and there is no SLA behind it.

Watch uptime, but audit health too

An uptime monitor tells you the moment your site stops answering. It says nothing about the certificate that expires on Sunday, the DMARC record that quietly broke, or the staff password sitting in a breach dump. FortifyNet's free scan takes about 60 seconds, needs no account, and covers SSL/TLS, DNS, email authentication, security headers, dark-web exposure and performance in one prioritised report.

Run your free FortifyNet scan and see what your uptime monitor cannot.

Related guides

Originally published at fortifynet.com/blog/pingdom-alternative. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

SSL/TLS Security Guide 2026: Achieve an A+ Rating

Håkan Fägnell — Tue, 11 Aug 2026 04:45:29 +0000

What is SSL/TLS and Why Does It Matter?

SSL (Secure Sockets Layer) and its modern successor TLS (Transport Layer Security) are cryptographic protocols that protect the connection between a web server and a browser. Think of them as a secure tunnel through which all data passes, encrypted so that no one can read or tamper with it along the way.

When you see a padlock icon in your browser address bar and the URL starts with "https://", that is SSL/TLS in action. Without it, any data your visitors send - login credentials, payment details, personal information - travels as plain text that anyone on the same network can intercept.

Key benefits of SSL/TLS:

Data Privacy means that all information exchanged between your server and your visitor is encrypted. Even if someone intercepts the traffic, they see only meaningless scrambled data. Data Integrity ensures that data cannot be silently modified in transit - any tampering breaks the connection. Authentication means the certificate proves that your site really is who it claims to be, protecting visitors from fake sites that impersonate yours. SEO benefit is real too - Google has used HTTPS as a ranking signal since 2014 and continues to reward secure sites.

The Evolution: From SSL to TLS 1.3

The first SSL protocol appeared in 1995. Over the years, researchers discovered serious security flaws in each version, driving the development of newer, stronger protocols.

SSL 2.0 and SSL 3.0 are completely broken and must be disabled. They are vulnerable to attacks like POODLE and DROWN. Any modern server should refuse these completely. TLS 1.0 and TLS 1.1 were improvements but are now deprecated - the Payment Card Industry (PCI DSS) compliance standard formally requires them to be disabled. TLS 1.2 is the current minimum acceptable standard. It is secure when configured correctly and is still widely supported. TLS 1.3 is the gold standard, released in 2018. It is faster than TLS 1.2 because it requires fewer round-trips to establish a connection, and it removes all the outdated, weak algorithms that made older versions vulnerable. Enabling TLS 1.3 while keeping TLS 1.2 gives you the best combination of security and compatibility.

How to Achieve an A+ Rating on SSL Labs

SSL Labs (ssllabs.com/ssltest) is the industry-standard tool for grading SSL/TLS configurations. An A+ rating means your server is configured at the highest level. Here is what you need to do:

Disable Legacy Protocols

The first step is to configure your server to refuse old, insecure protocol versions. On nginx, open your configuration file and set the protocols line to allow only TLS 1.2 and 1.3. On Apache, you use the SSLProtocol directive to achieve the same result. This one change alone eliminates many common vulnerabilities.

Use Strong Cipher Suites

A cipher suite is the combination of algorithms used to encrypt your connection. Older cipher suites using algorithms like RC4, 3DES, or MD5 are weak and should be disabled. Modern configurations use suites based on ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange combined with AES-GCM encryption. The key word is "ephemeral" - it ensures Perfect Forward Secrecy, meaning that even if your server's private key is somehow obtained in the future, past communications cannot be decrypted.

Enable HTTP Strict Transport Security (HSTS)

HSTS is a security policy sent as an HTTP header that tells browsers: "This site should always be accessed over HTTPS. If you ever see an HTTP link to this site, upgrade it to HTTPS automatically." This prevents downgrade attacks where an attacker tries to trick your visitor's browser into connecting over unencrypted HTTP.

The header should include a long max-age (at least one year), the includeSubDomains flag to cover all your subdomains, and the preload flag if you plan to submit to the HSTS preload list - a list hardcoded into browsers so that even the very first visit to your site is protected.

Enable OCSP Stapling

When a browser connects to your site, it needs to verify that your certificate has not been revoked. Normally this requires the browser to make a separate request to your Certificate Authority, which adds delay. OCSP Stapling solves this by having your server fetch and cache the validity proof from the CA and then bundle it directly into the TLS handshake. This makes connections faster and eliminates a privacy concern - the CA no longer learns which sites your visitors are connecting to.

Certificate Types Explained

There are several types of SSL certificates, differing in how thoroughly your identity is verified before the certificate is issued.

Domain Validated (DV) certificates are the simplest. The CA just checks that you control the domain by having you add a DNS record or a file to your website. Let's Encrypt issues DV certificates for free. They provide full encryption and are perfectly suitable for most websites.

Organization Validated (OV) certificates require the CA to verify your organization's legal existence. This adds a layer of trust but is not visible to regular users without digging into certificate details.

Extended Validation (EV) certificates involve the strictest vetting - the CA verifies your organization's legal identity, physical address, and operational status. They are used by banks and major e-commerce sites.

Wildcard certificates cover your main domain and all its subdomains with a single certificate - useful if you run multiple subdomains.

Can a free Let's Encrypt certificate achieve an A+ rating? Absolutely yes. The grade you receive from SSL Labs depends entirely on your server configuration, not on what type of certificate you have or how much you paid for it.

Certificate Renewal and Automation

SSL certificates expire. When they do, browsers immediately show security warnings to all your visitors - a catastrophic outcome for any business. Let's Encrypt certificates are valid for 90 days, and commercial certificates typically last one year.

The solution is automation. The certbot tool, provided by Let's Encrypt, can automatically renew certificates before they expire. Set it to run twice per day via a scheduled task. FortifyNet monitors your certificate expiry dates and sends you alerts 30 days and 7 days before expiry, giving you plenty of time to act even if automation fails.

Common Mistakes to Avoid

Incomplete certificate chain is the most common issue. Your server must send not just your certificate, but also any intermediate certificates in the chain. Without them, some browsers will reject your certificate. Mixed content occurs when your HTTPS page loads resources - images, scripts, fonts - over HTTP. This breaks the secure connection and shows security warnings. Expired certificates are entirely avoidable with automation. Self-signed certificates are only appropriate for internal development - they will never be trusted by browsers for public-facing sites.

Frequently Asked Questions

What is the difference between SSL and TLS? TLS is the modern, secure replacement for SSL. The term "SSL" is still used colloquially but all modern secure connections actually use TLS 1.2 or 1.3. SSL 2.0 and SSL 3.0 are broken and should never be used.

How often should I renew my SSL certificate? Let's Encrypt certificates are valid for 90 days and should be renewed automatically every 60 days. Commercial certificates typically last one year. Always use automation - manual renewal is error-prone and frequently forgotten.

Can a free certificate be as secure as a paid one? Yes, completely. The encryption strength is identical. The only difference is the level of identity verification and whether a financial warranty is included. For most websites, a free Let's Encrypt certificate is the right choice.

Why does my site show "Not Secure" even though I have a certificate? The most common cause is mixed content - your HTTPS page is loading some resources over HTTP. Open your browser's developer console and look for Mixed Content warnings. Update all resource URLs to use HTTPS.

What is a downgrade attack? An attacker positioned between your visitor and your server tricks the browser into connecting over HTTP or an older, weaker version of TLS. HSTS prevents this by instructing browsers to always use HTTPS, and the preload list ensures this protection applies from the very first visit.

Originally published at fortifynet.com/blog/ssl-tls-certificate-security. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

GTmetrix Alternative: 6 Best Options in 2026 | FortifyNet

Håkan Fägnell — Mon, 10 Aug 2026 04:45:29 +0000

The best GTmetrix alternative depends on what pushed you away in the first place. If the free plan is the problem, WebPageTest Starter gives you 150 test runs per month at no cost, against GTmetrix Basic's 5 tests per month for three months (GTmetrix, August 2026). If you want field data straight from Google, PageSpeed Insights is free and uncapped. And if you want to know whether a slow page is also an exposed page, FortifyNet checks performance next to SSL/TLS, DNS, email authentication and security headers in one 60-second scan.

Below is an honest comparison of six options, with current prices and limits taken from each vendor's own pricing page in August 2026.

Why people start looking for a GTmetrix alternative

GTmetrix is still a good tool. It is the free tier that changed. A GTmetrix Basic account today gets 5 On-Demand tests per month for three months, testing from two locations (Seattle and London), with one month of monitoring history (GTmetrix free plan features).

That is enough to look at a page once. It is not enough to iterate: change a setting, retest, compare, retest again. A single afternoon of optimisation work can burn a month's allowance.

The paid tiers are reasonably priced but tightly scoped at the bottom. The entry Lite plan is $5.99/month billed monthly, or $59.90 billed yearly, and it includes 50 On-Demand tests, 1 monitored slot, 5 test locations and just 1 month of data retention. You need the Advanced plan at $29.99/month (or $299.90/year) before you get unlimited on-demand tests, hourly monitoring, 10 monitored slots and 25 locations (GTmetrix pricing, August 2026).

If you manage more than one site, or you want a year of history to prove a regression to a client, that is where the search for an alternative usually starts.

What actually matters when you compare speed tools

Before the table, three things worth being clear about.

Lab data and field data are not the same thing. A GTmetrix or WebPageTest run is lab data: one synthetic load, from one machine, on one connection. Google's Core Web Vitals assessment uses field data, real visits from real Chrome users, evaluated at the 75th percentile. A tool can show you a beautiful lab score while your actual users are failing.

The 2026 thresholds are unchanged. To pass Core Web Vitals a page needs LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, each at the 75th percentile of real users. Poor starts at LCP over 4 seconds, INP over 500 milliseconds and CLS over 0.25 (web.dev). INP replaced FID as the responsiveness metric, so any tool still reporting FID as a Core Web Vital is out of date.

Retention is the sleeper feature. Scores are easy to get. Proving that last Tuesday's deploy is what slowed the page down requires history. This is exactly where free tiers differ most.

The 6 best GTmetrix alternatives compared

Tool	Free tier	Paid from	Free test locations	Data retention (free)	Field data (CrUX)
WebPageTest (Catchpoint)	150 test runs/mo	$180/yr (1,000 runs/mo)	30 worldwide	60 days	No
Google PageSpeed Insights	Unlimited, no account	Free	Google infrastructure	Not stored	Yes
FortifyNet	Full 60-second audit	Freemium	Global	Scan history in account	Partial
Pingdom (SolarWinds)	None, 14-day trial	~$15/mo synthetic	Paid only	Paid only	No
DebugBear	None, 14-day trial	Paid only	Paid only	Paid only	Yes
Chrome DevTools / Lighthouse	Unlimited, local	Free	Your own machine	Not stored	No
GTmetrix (for reference)	5 tests/mo for 3 mo	$5.99/mo	2 (Seattle, London)	1 month	Yes, 1-month CrUX

Sources: vendor pricing pages, August 2026. Pingdom and DebugBear entry prices vary between resellers and are quoted as approximate.

1. WebPageTest, the closest like-for-like swap

If you liked GTmetrix's waterfall charts and filmstrips, WebPageTest is the natural move. The free Starter plan includes 150 test runs per month, 30 global test locations, filmstrip and video capture, Lighthouse, the Opportunities report and 60 days of test history (Catchpoint pricing).

WebPageTest Pro starts at $180/year for 1,000 runs per month and adds scheduled tests, alerts, the API, private tests, bulk testing, 35 locations including mainland China, up to 5 team seats and 13 months of retention. Note that a "test run" is a single page load, so a test with first and repeat views counts as two.

Best for: developers who want depth, and anyone whose main complaint about GTmetrix was the test allowance.

2. Google PageSpeed Insights, the free authority

PageSpeed Insights is the only tool on this list that shows you the exact field data Google uses for the Core Web Vitals assessment, drawn from the Chrome User Experience Report. It is free, uncapped and needs no account.

The trade-off is that it stores nothing. There is no history, no monitoring, no alerts, no comparison between two runs. Use it as the referee, not the workbench. We cover this in more depth in our Google PageSpeed alternatives comparison.

Best for: confirming whether Google thinks your page passes.

3. FortifyNet, when speed is only half the question

Most speed tools answer "is this page fast?" and stop. A slow page is often a symptom of something else: an expired or misconfigured certificate adding handshake delays, DNS that resolves slowly, third-party scripts nobody audited, missing compression.

FortifyNet's free 60-second scan runs performance checks alongside SSL/TLS configuration, DNS records, email authentication (SPF, DKIM and DMARC), HTTP security headers and dark-web exposure for your domain, then gives you one prioritised list. If you are the only technical person at a small company, one report beats five tabs.

Best for: site owners who want the performance and security picture together rather than a specialist speed lab.

4. Pingdom, for uptime plus speed

Pingdom's strength was never really page analysis, it is availability monitoring: is the site up, from where, and who gets paged. SolarWinds retired the free tier, so you now start with a 14-day trial, and synthetic monitoring plans begin around $15/month and scale with the number of checks.

Best for: teams whose real requirement is uptime alerting, with speed as a bonus.

5. DebugBear, for continuous Core Web Vitals

DebugBear is a specialist: scheduled synthetic tests plus real user monitoring, built specifically around Core Web Vitals and Lighthouse trends. There is no free tier, only a 14-day trial, and the entry plan is limited to a single project, which matters if you are an agency.

Best for: performance engineers who need field and lab data in one dashboard and have budget for it.

6. Chrome DevTools and Lighthouse CLI, free and local

The tool already on your machine. Open DevTools, run a Lighthouse audit, and you get the same engine PageSpeed Insights uses in its lab section, with unlimited runs and no queue. For automation, the Lighthouse CLI runs from npm as npx lighthouse and outputs JSON or HTML you can commit to a repo.

The catch: it tests from your machine, on your connection, with your extensions. Results are not comparable to a clean cloud test unless you are careful.

Best for: developers iterating locally before running a public test.

Free-tier limits, side by side

Free monthly test allowances, August 2026. PageSpeed Insights and local Lighthouse runs are uncapped and are excluded from the chart.

How to switch without losing your baseline

Export what you have. Before your GTmetrix retention window closes, screenshot or export the reports you might need as evidence later. On Basic, history is short.
Record a reference run. Test your three most important pages in the new tool on the same day, same location, same connection setting. That becomes your new baseline.
Match the analysis options. A GTmetrix score taken from London on a throttled connection will not match a WebPageTest run from Dulles on cable. Fix location, device and throttling before comparing anything.
Check the field data separately. Run PageSpeed Insights on the same URLs and note the 75th-percentile LCP, INP and CLS. Lab numbers guide your work, field numbers decide whether you pass.
Set up monitoring on one page first. Most free tiers allow a single monitored page. Pick the highest-traffic entry page rather than the homepage if they differ.

Which one should you pick?

Want the closest replacement with a generous free tier: WebPageTest.
Want to know if Google thinks you pass: PageSpeed Insights.
Want performance and security in one report: FortifyNet.
Want alerts when the site goes down: Pingdom.
Want continuous Core Web Vitals with real user data: DebugBear.
Want to iterate locally at zero cost: Chrome DevTools.

For most small businesses, the practical answer is a pair: WebPageTest or FortifyNet for the working audit, and PageSpeed Insights as the final check against Google's own field data.

FAQ

Is GTmetrix still free in 2026?
There is still a free GTmetrix Basic account, but it is limited to 5 On-Demand tests per month for three months, two test locations and one month of data retention. It is a trial in practice rather than an ongoing free tier.

Which GTmetrix alternative is the most accurate?
No lab tool is definitive, because lab tests are single synthetic loads. For the numbers Google actually uses in ranking, PageSpeed Insights field data (or Search Console's Core Web Vitals report) is authoritative. Lab tools are for diagnosis, not verdicts.

Why does my GTmetrix grade differ from my PageSpeed score?
Because they weight different metrics and test from different places under different network conditions. Chasing identical numbers across tools is wasted effort. Pick one lab tool, keep its settings constant, and track the trend.

Can a slow site hurt my search rankings?
Core Web Vitals are part of Google's page experience signals, assessed on field data at the 75th percentile. They are one input among many, not a switch. A page that fails badly is at a disadvantage; a page that passes comfortably gains no special boost.

Do security issues affect page speed?
They can. Misconfigured TLS, redirect chains from HTTP to HTTPS to www, slow DNS resolution and unaudited third-party scripts all add real milliseconds before your content starts rendering.

Check speed and security in the same scan

A fast site that leaks email through a missing DMARC record is still a liability. FortifyNet's free scan takes about 60 seconds, needs no account and covers SSL/TLS, DNS, SPF, DKIM, DMARC, HTTP security headers, dark-web exposure and performance in one prioritised report.

Run your free FortifyNet scan and see the whole picture, not just the speed number.

Related guides

Originally published at fortifynet.com/blog/gtmetrix-alternative. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

Dark Web Monitoring Guide for Businesses 2026

Håkan Fägnell — Sun, 09 Aug 2026 04:45:29 +0000

What Is the Dark Web?

The internet is not one uniform space - it has layers. The surface web is the part you access through Google, Bing, or any other search engine. It represents only a small fraction of all internet content. The deep web is the much larger portion of the internet that is not indexed by search engines - your email inbox, your bank's internal pages, corporate intranets, and databases all live here. The dark web is a specific portion of the deep web that is intentionally hidden and can only be accessed using specialized software, most commonly the Tor browser.

The dark web is not inherently criminal. It has legitimate uses: investigative journalists use it to communicate with sources in countries where press freedom is restricted, activists in authoritarian regimes use it to organize safely, and privacy advocates use it to avoid surveillance. However, it is also home to criminal marketplaces where stolen data is bought and sold at scale.

When a data breach occurs at any company that holds your data - a social media platform, a software tool your employees use, a healthcare provider, an e-commerce site - that stolen data often ends up for sale on dark web marketplaces within hours or days of the breach. The buyers are typically other cybercriminals who use the credentials to attack corporate systems.

How Credentials End Up Compromising Your Business

The path from a third-party data breach to a successful attack on your organization typically works as follows. A breach occurs at some service - LinkedIn, Adobe, Dropbox, Trello - any platform that your employees happen to use with their work email address. Millions of email and password combinations are extracted and sold on dark web forums.

The buyers of this data run automated "credential stuffing" attacks. They take the list of breached email/password combinations and systematically test them against corporate login portals - your VPN, your email platform (Microsoft 365 or Google Workspace), your HR system, your project management tools. If even one employee has reused the same password across their personal account on the breached service and their corporate account, the attacker gains access.

This is not theoretical. Credential stuffing is the cause of a significant portion of corporate account takeovers. Research consistently shows that 60-70% of people reuse passwords across multiple services. This means that a breach at one company creates a risk vector for your organization even though you were not the breached party.

How Dark Web Monitoring Works

Dark web monitoring services - like the capability built into FortifyNet - continuously monitor known breach databases, dark web forums, and paste sites for credentials associated with your organization's domain. When they find an email address ending in your domain in a breach database, they alert you.

FortifyNet uses the HaveIBeenPwned (HIBP) API, built by security researcher Troy Hunt. HIBP is the largest and most comprehensive publicly available database of compromised credentials, containing over 14 billion records from thousands of breaches. The database is updated whenever new breach data becomes available, which means you receive alerts not just about historical breaches but about new ones as they emerge.

An important technical note: the way FortifyNet queries this database protects your privacy. Rather than sending your email addresses or passwords to the API, it uses a technique called k-anonymity. Only the first five characters of a hashed credential are sent - enough to look up a list of potential matches, which are then compared locally. Your actual credentials are never transmitted.

Understanding What Breach Data Tells You

When FortifyNet detects that credentials from your domain are exposed, you will see specific information about each breach: which service was compromised, what types of data were exposed (email addresses, passwords, names, phone numbers, and so on), when the breach occurred, and how many records from your domain were involved.

This information is actionable. If the breach occurred in 2018 and exposed only email addresses (not passwords), the risk level is lower - but those email addresses can still be used for targeted phishing. If the breach exposed password hashes from 2022, those hashes may have already been cracked and the plaintext passwords circulated. Even old breaches matter because password reuse means a five-year-old breach can still unlock accounts today.

Incident Response When Credentials Are Found

Discovering that your organization's credentials appear in breach databases requires an immediate, structured response. The priority in the first 24 hours is to contain the exposure: identify every affected email address and account, force immediate password resets for those accounts, enable or verify that multi-factor authentication (MFA) is active on all affected accounts, and review access logs for those accounts over the past 90 days to identify any suspicious activity that may have already occurred.

Within the first week, the focus shifts to prevention and communication: notify affected employees (frame this as a security alert to help them, not as an accusation), conduct awareness training on password hygiene and the risks of password reuse, review whether those accounts had access to sensitive systems that may have been compromised, and consider whether any data that those accounts could access may now be at risk.

If your organization is subject to GDPR and the breach involves personal data of EU citizens, you may have an obligation to notify your supervisory authority within 72 hours of becoming aware of a breach. This is why having a monitoring service that alerts you promptly is valuable - it starts the clock for your notification obligation.

Preventing Future Exposures

The most effective preventive measures are also the simplest. Requiring strong, unique passwords enforced through a corporate password manager eliminates the password reuse problem at its root. When employees use different passwords everywhere, a breach at one service cannot compromise their corporate accounts.

Multi-factor authentication (MFA) is the single most effective control for preventing account takeover even when credentials are compromised. An attacker who obtains a correct password still cannot log in without the second factor. Hardware security keys (FIDO2/WebAuthn) are the strongest form of MFA because they are phishing-resistant - they cryptographically bind the authentication to the specific website being logged into, making it impossible for a phishing site to steal the factor.

Frequently Asked Questions

How many breached accounts is serious? Any number. Even one exposed account belonging to an employee with elevated privileges - an IT administrator, a financial approver, an HR manager - can be catastrophic. Treat every alert as high priority regardless of count.

We use Google Workspace and they have strong security. Are we still at risk? Yes. The risk is not Google being breached - it is your employees using the same password for their Google account that they used for some other service that was breached. Google's security is excellent, but it cannot protect against correct passwords being used.

How long does it take for breached data to appear in monitoring services? Major breaches are typically discovered and added to databases like HIBP within days to weeks of the breach becoming known. However, some breaches circulate privately on dark web forums for months before becoming public. This is why continuous monitoring matters - the data keeps expanding.

We changed all passwords after a breach alert. Are we safe? Yes, if you also enabled MFA on affected accounts. Passwords alone are not sufficient - MFA ensures that even if future credentials are compromised, attackers cannot use them.

Should we tell affected employees which specific service their credentials came from? Yes. Employees should know so they can also change their passwords on that personal service, and so they understand the specific risk. Transparency builds security culture rather than undermining it.

Originally published at fortifynet.com/blog/dark-web-monitoring-guide. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

GDPR Compliance Security Audit Guide 2026 | FortifyNet

Håkan Fägnell — Sat, 08 Aug 2026 04:45:29 +0000

⚠️ Disclaimer: This article is a general educational guide and does not constitute legal advice. Laws and regulations may vary depending on your country, industry, and specific situation. Always consult a qualified legal advisor or data protection specialist for guidance tailored to your organization.

Introduction: What This Guide Covers

GDPR can feel overwhelming - especially when you're running a website and trying to understand what it actually means for your day-to-day operations. This guide breaks down the key technical and organizational areas you should be aware of, in plain language.

We're not here to scare you. Most of what GDPR requires for websites is practical common sense: keep your systems secure, be transparent about what data you collect, and have a plan if something goes wrong.

The Core Idea: "Appropriate Security"

At its heart, GDPR's Article 32 asks organizations to implement security measures that are "appropriate to the risk." This means there's no single checklist - your obligations depend on what kind of data you handle and how sensitive it is.

A small blog that collects newsletter sign-ups has different requirements than a healthcare platform handling medical records. But for almost any website that collects personal data, some baseline security measures are generally expected:

HTTPS/SSL - encrypted connections between your website and visitors
Access controls - limiting who can access personal data internally
Incident detection - knowing when something goes wrong
Regular security reviews - checking that your protections are still working

One important thing: you need to be able to show that you're doing these things, not just say you are. Documentation matters.

Cookies: More Than Just a Banner

Cookie consent is one of the most visible parts of GDPR compliance - and also one of the most commonly misunderstood.

The basic rule: any cookie that isn't strictly necessary for your website to function requires the visitor's prior, informed consent. That means:

Analytics tools like Google Analytics need consent
Marketing pixels (Facebook, LinkedIn, etc.) need consent
Session cookies for login are generally necessary and don't need consent

A valid consent mechanism means the user can easily say no just as easily as yes. Pre-ticked boxes don't count. A huge "Accept All" button next to a tiny grey "Manage settings" link is also problematic.

And here's the technical detail that trips up many websites: cookies must not be set before consent is given. Many sites load tracking scripts in the background while the consent banner is still showing - this is a violation regardless of what the banner says.

Your Privacy Policy

A privacy policy is a legal requirement if you collect any personal data. But it needs to contain specific information, not just general statements.

At a minimum, it should explain:

Who is collecting the data (your organization's name and contact)
What data you collect and why
What legal basis you're using (consent, legitimate interest, etc.)
Who you share data with
How long you keep the data
What rights users have (access, deletion, correction, etc.)

Vague statements like "we may share data with partners" typically don't meet the standard. Be specific.

If Something Goes Wrong: Breach Notification

If you have a personal data breach - someone gains unauthorized access to your users' data - you may have legal obligations to report it.

Under GDPR Article 33, you generally need to notify your national data protection authority within 72 hours of becoming aware of a breach, if it poses a risk to people's rights. In Sweden, that authority is IMY (Integritetsskyddsmyndigheten).

This is why monitoring your systems matters - the faster you detect a problem, the more time you have to respond and report correctly.

Note: Not every incident needs to be reported. Whether a breach triggers notification obligations depends on the nature and severity of the incident. Consult legal advice for your specific situation.

A Note on NIS2

The NIS2 Directive is an EU cybersecurity regulation that came into effect in October 2024. It applies to organizations in specific sectors (energy, healthcare, finance, digital infrastructure, and others) and sets stricter cybersecurity requirements than GDPR.

If you're in one of these sectors, NIS2 is worth investigating further - ideally with a specialist who knows your industry. The incident reporting timelines under NIS2 are tighter than GDPR (24 hours for initial notification).

This guide doesn't cover NIS2 in depth, as its applicability varies greatly by organization type and country.

Common Questions

Do I need a Data Protection Officer (DPO)?
Most small and medium websites do not. A DPO is generally required if you're a public authority, or if your core business involves large-scale processing of sensitive data. When in doubt, check with a legal advisor.

Do I need to register with a data protection authority?
In most EU countries, you don't need to proactively register. But you do need to maintain internal records of your data processing activities (called a RoPA).

How do I know if my website is technically compliant?
A security audit can help identify technical gaps - things like expired SSL certificates, missing security headers, or cookies firing before consent. Tools like FortifyNet can give you a quick overview of your website's technical security posture.

Where to Get Proper Legal Advice

This guide is meant to give you a starting point - not a complete answer. GDPR compliance depends on your specific situation, the data you process, your country, and your industry.

For proper guidance, consider:

Your national data protection authority's website (e.g., imy.se for Sweden)
A qualified data protection lawyer or consultant
Your company's legal team if you have one

Don't rely solely on blog articles (including this one!) for legal compliance decisions.

Originally published at fortifynet.com/blog/gdpr-compliance-security-audit. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

What Is DKIM? Email Signing Explained | FortifyNet

Håkan Fägnell — Fri, 07 Aug 2026 04:45:29 +0000

DKIM (DomainKeys Identified Mail) is an email authentication standard, defined in RFC 6376, that attaches a cryptographic signature to every message your domain sends. The receiving mail server looks up your public key in DNS, recomputes the signature over the message body and selected headers, and confirms two things: the mail really came from your domain, and nobody altered it in transit. If you send email from your own domain, DKIM is no longer a nice-to-have. Google and Yahoo have required it from bulk senders since February 2024, and Microsoft began rejecting non-compliant high-volume mail to Outlook.com, Hotmail.com and Live.com on 5 May 2025 (Microsoft Defender for Office 365 blog).

How DKIM actually works

DKIM is a public-key signature scheme wrapped around SMTP. The flow has four steps:

You generate a key pair. The private key stays on your sending mail server or with your email provider. The public key is published in DNS.
Your server signs outbound mail. It hashes the message body plus a chosen list of headers (From, Subject, Date and others), signs that hash with the private key, and inserts the result as a DKIM-Signature: header.
The receiver fetches your public key. It reads the domain (d=) and selector (s=) from the signature header and queries <selector>._domainkey.<domain> for a TXT record.
The receiver verifies. It recomputes the hash and checks it against the signature. A match means the signed parts of the message are authentic and unmodified.

Crucially, DKIM survives forwarding in a way SPF does not. SPF validates the connecting IP address, so it breaks the moment a mailing list or forwarder relays your message. A DKIM signature travels with the message itself, which is why DKIM alignment is usually the more durable half of a DMARC policy.

Anatomy of a DKIM record

A published DKIM record is a DNS TXT record at a selector-specific hostname. Here is a trimmed example for the selector s1 on example.com, published at s1._domainkey.example.com:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The tags you will meet most often:

Tag	Where it appears	Meaning
`v=`	DNS record	Version, always `DKIM1`
`k=`	DNS record	Key type: `rsa` (default) or `ed25519`
`p=`	DNS record	The Base64 public key. An empty `p=` revokes the key
`t=y`	DNS record	Testing mode. Receivers should not penalise failures
`d=`	Signature header	The signing domain, the one DMARC aligns against
`s=`	Signature header	Selector, so one domain can hold many keys
`h=`	Signature header	The list of headers covered by the signature
`bh=`	Signature header	Hash of the canonicalised body
`x=`	Signature header	Signature expiry, as a Unix timestamp

One detail trips up almost everyone: a 2048-bit RSA public key is longer than the 255-byte limit for a single DNS character string, so it must be published as multiple quoted strings that the resolver concatenates. Some DNS panels do this silently, others do not, and a mis-chunked key fails verification without any visible error.

How to set up DKIM in five steps

Generate a 2048-bit RSA key pair, or let your provider generate it. Google Workspace, Microsoft 365, Zoho, Mailgun, SendGrid, Postmark and Amazon SES all issue keys from their admin consoles.
Pick a descriptive selector. Use one per sending source, for example google1, mg-2026a, zoho._domainkey. Never reuse a selector across two systems.
Publish the TXT record at <selector>._domainkey.<yourdomain>. Wait for propagation, which usually takes minutes but can take up to the TTL of the parent zone.
Enable signing in the sending platform. Publishing the key without turning on signing is the single most common half-finished DKIM deployment.
Verify. Query the record from a terminal with dig TXT s1._domainkey.example.com +short, then send a test message to a mailbox you control and read the Authentication-Results: header. You want to see dkim=pass.

Repeat this for every system that sends as your domain: your mail host, your marketing platform, your invoicing tool, your helpdesk. Each one needs its own selector and its own key.

DKIM vs SPF vs DMARC

The three standards are complementary, not alternatives. DKIM proves integrity, SPF authorises the sending path, and DMARC ties either result back to the visible From address and tells receivers what to do on failure.

	SPF	DKIM	DMARC
Defined in	RFC 7208	RFC 6376	RFC 7489
What it validates	Sending IP address	Message signature	Alignment of SPF or DKIM with the From domain
Survives forwarding	No	Yes	Depends on DKIM surviving
Crypto involved	None	Public-key signature	None
DNS records needed	One TXT per domain	One TXT per selector	One TXT at `_dmarc`
Typical failure cause	Exceeding 10 DNS lookups	Missing or mis-chunked key	Neither mechanism aligned
Reporting built in	No	No	Yes, aggregate and forensic

DKIM remains the least deployed of the three. A February 2026 scan of 5.5 million domains put SPF at 56.0%, DMARC at 30.4% and DKIM at 22.7% (DMARCguard research). The authors note DKIM is likely undercounted, because a scanner can only probe common selectors and cannot discover custom ones.

Key length, rotation, and the replay problem

Use 2048-bit RSA. RFC 8301 deprecated signing keys below 1024 bits, and NIST SP 800-57 treats 2048 bits as the current floor for RSA. 1024-bit keys still verify at most receivers but are on borrowed time. Going to 4096 bits buys little and makes DNS publishing harder.

Rotate on a schedule. RFC 6376 recommends periodic rotation without naming an interval; M3AAWG's best common practices and most operators land on every 6 to 12 months, or quarterly in regulated environments. Rotation is safe if you do it in the right order: publish the new selector, sign with the new key while the old record is still live, confirm passes in your DMARC aggregate reports, then remove the old record.

Understand DKIM replay. In April 2025 a phishing campaign abused a legitimately signed Google message, re-sending it verbatim to new victims so it arrived with a valid dkim=pass from google.com (Red Sift analysis). Nothing about the signature was forged. The attack works because a DKIM signature says nothing about who sent the message or to whom. Two practical mitigations: oversign the headers that matter by listing them in the h= tag more times than they appear, which blocks an attacker from appending a second To: or Subject: header, and set a short signature expiry with the x= tag to shrink the replay window.

Common DKIM failures and what causes them

Symptom	Likely cause	Fix
`dkim=none` in headers	Signing not enabled at the sender	Turn on DKIM in the platform, not just DNS
`dkim=permerror`	Record missing, or `p=` mis-chunked	Re-publish as split quoted strings
`dkim=fail` on forwarded mail only	A list or gateway rewrote the body or a signed header	Ask the forwarder to use ARC, or rely on SPF alignment for that path
Passes for one system, fails for another	A sending source has no selector of its own	Add a dedicated key per source
DMARC fails despite `dkim=pass`	The `d=` domain does not align with the From domain	Sign with your own domain, not the provider's

Frequently asked questions

Does DKIM encrypt my email?
No. DKIM signs, it does not encrypt. Anyone who intercepts the message can still read it. Transport encryption is TLS, and content encryption is S/MIME or PGP.

Can I have more than one DKIM record?
Yes, and you usually should. Each selector is a separate record, so one domain can carry a key for every sending platform you use.

Does DKIM alone stop spoofing?
No. A valid signature proves a message was signed by some domain, but receivers only act on that if a DMARC policy tells them to. DKIM plus DMARC at p=quarantine or p=reject is what actually blocks spoofed mail.

What happens when I delete a DKIM key?
Any message still in flight that was signed with it will fail verification. To revoke deliberately, publish the record with an empty p= rather than deleting it outright, so receivers see an explicit revocation.

Is Ed25519 ready to use?
Ed25519 signing is standardised in RFC 8463 and produces far shorter DNS records, but verifier support is still uneven. Dual-sign with RSA-2048 alongside it rather than switching outright.

Related guides

Check your DKIM in 60 seconds

Most broken DKIM setups look fine from the admin console and only reveal themselves in the headers of delivered mail. FortifyNet's free scan reads your live DNS and reports on SPF, DKIM and DMARC together, alongside your SSL/TLS configuration, security headers and dark-web exposure. No signup required. Run a free scan of your domain and see what receivers actually see.

Originally published at fortifynet.com/blog/what-is-dkim. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

Mozilla Observatory Alternative 2026 | FortifyNet

Håkan Fägnell — Thu, 06 Aug 2026 04:45:29 +0000

Mozilla Observatory Alternative: The Best Replacements in 2026

For almost a decade, Observatory by Mozilla was the default free answer to the question "how secure is my website's configuration?". Then it was retired. The HTTP scanning half found a new home on MDN in July 2024, while the rest of the toolkit, including the TLS Observatory and the SSH Observatory, was shut down for good in September 2024, as documented in MDN's launch announcement.

If you still have observatory.mozilla.org bookmarked, or your security checklist references tests that no longer exist, you need a replacement. This guide compares the best Mozilla Observatory alternatives in 2026, explains exactly what each one covers, and shows how to rebuild your old scanning workflow without losing coverage.

What happened to Mozilla Observatory?

Observatory started in 2016 as an internal Mozilla tool, built by security engineer April King to push Mozilla's own websites toward modern security practices. Once opened to the public it became a fixture of the web security community: by the time of the migration it had scanned 6.9 million websites across 47 million scans, according to MDN.

Date	Event
2016	Observatory by Mozilla launches publicly
2016 to 2024	6.9 million websites scanned, 47 million total scans
July 2, 2024	HTTP Observatory relaunches on MDN with an updated test suite
September 2024	observatory.mozilla.org is sunset; the TLS and SSH Observatories retire with it

The migration was not a simple rebrand. The MDN team modernized the tests:

The outdated X-XSS-Protection test was removed.
Legacy Flash and Silverlight cross-domain policy tests were removed.
A new Cross-Origin-Resource-Policy (CORP) test was added.
Referrer-Policy scoring was updated.
Scans are now rate-limited to one per site every 60 seconds.

One change matters more than all the others: the new MDN HTTP Observatory analyzes HTTP response security only. Mozilla states there are no plans to bring back the TLS and certificate analysis tabs. If your old routine was "run Observatory, fix the headers, then check the TLS tab", the second half of that workflow now needs a different tool.

What to look for in a replacement

Three questions separate the candidates quickly:

Coverage. Headers are one layer. A realistic external audit also covers TLS configuration and certificate expiry, DNS records, email authentication (SPF, DKIM, DMARC), and ideally whether your credentials already circulate on the dark web.
Actionability. A letter grade is motivating, but the report should tell you which header to change and what value to set, not just that something failed. Observatory's gamified hunt for the A+ worked precisely because it paired grades with documentation.
Workflow fit. Rate limits, scan speed, whether you can monitor continuously or only scan manually, and price.

With those criteria in mind, here are the tools worth your time in 2026.

The best Mozilla Observatory alternatives in 2026

1. FortifyNet: the closest thing to a full Observatory successor

FortifyNet runs a free scan in about 60 seconds and covers the six areas most external audits care about: security headers, SSL/TLS configuration and certificate expiry, DNS health, email authentication (SPF, DKIM and DMARC), dark web exposure of your domain's credentials, and performance basics. Results come back as a graded report with concrete fixes written in plain language.

That breadth is the point. The old Mozilla Observatory bundled HTTP and TLS testing in one place; FortifyNet restores that single-dashboard experience and extends it to email authentication and breach exposure, which Mozilla never covered. The scan itself is free with no signup, while continuous monitoring and alerting sit in the paid plans, so the model is freemium rather than purely free.

Best for: teams that want the whole external security picture in one scan.

Limitations: it is a breadth-first audit, not a deep penetration test.

2. MDN HTTP Observatory: the official successor

The MDN HTTP Observatory is the direct descendant and remains excellent at its narrower job. It runs roughly ten tests against your HTTP responses: Content-Security-Policy, cookie configuration, CORS, Strict-Transport-Security, redirection behavior, Referrer-Policy, Subresource Integrity, X-Content-Type-Options, clickjacking protection via frame-ancestors and X-Frame-Options, and CORP. Every failed test links straight into MDN's security guides, which are among the best free documentation on the subject, and historic scan data from the old Observatory was preserved.

Best for: deep, well-documented header and policy analysis.

Limitations: no TLS, certificate, DNS or email checks; one scan per minute per site.

3. securityheaders.com: the fastest header grade

Scott Helme's securityheaders.com, which now operates under Snyk, is the quickest way to get an A+ to F grade on your response headers, and it had already passed 250 million scans in 2023. It checks the presence and sanity of the headers that matter most: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.

Best for: instant spot checks and shareable grades.

Limitations: headers only, and the remediation guidance is thinner than MDN's.

4. Qualys SSL Labs: the TLS deep dive

The retired TLS Observatory has an obvious replacement: the SSL Labs Server Test has been the reference TLS analyzer for years. It grades protocol support, cipher suites, key exchange, certificate chain correctness and known vulnerabilities, and it is free.

Best for: TLS and certificate configuration in depth.

Limitations: TLS only, and a full scan can take a few minutes per host. Our guide to earning an A+ TLS rating pairs well with it.

5. Internet.nl: the standards compliance angle

Internet.nl, run by the Dutch Internet Standards Platform, tests websites and mail domains against modern open standards: IPv6, DNSSEC, HTTPS and TLS settings, security headers, and on the email side SPF, DKIM, DMARC, STARTTLS and DANE, plus RPKI and security.txt. It produces a percentage score rather than a letter grade.

Best for: checking standards adoption across web and email in one pass.

Limitations: reports read more like a compliance checklist than a fix-it guide.

Also worth knowing: Hardenize, the configuration monitor created by SSL Labs author Ivan Ristić, was acquired and now lives inside Red Sift's commercial attack surface management product, so it is no longer the free quick-scan it once was. For the retired SSH Observatory, the open source ssh-audit project remains the practical community replacement.

Side-by-side comparison

Tool	Focus	Grading	TLS analysis	Email auth	Dark web	Price
FortifyNet	Full external audit	A+ to F	Yes	Yes	Yes	Freemium
MDN HTTP Observatory	HTTP headers and policies	A+ to F	No	No	No	Free
securityheaders.com	HTTP headers	A+ to F	No	No	No	Free
Qualys SSL Labs	TLS and certificates	A+ to F	Yes	No	No	Free
Internet.nl	Open standards, web and email	Percentage	Yes	Yes	No	Free

Counting six common audit areas (security headers, TLS, DNS, email authentication, dark web exposure, performance), coverage compares like this:

Number of the six audit areas each tool covers. The specialized tools go deeper within their single area; the chart shows breadth, not depth.

Rebuilding your old Observatory workflow

If you used	For	Use this now
HTTP Observatory	Header grading and docs	MDN HTTP Observatory, or FortifyNet for headers plus everything else
TLS Observatory	Protocol and certificate analysis	Qualys SSL Labs or FortifyNet
Third-party tests tab	Aggregated multi-tool view	FortifyNet's single dashboard
SSH Observatory	SSH configuration	The open source ssh-audit tool

Whichever combination you choose, header fundamentals still decide most of the grade. Our guides to HTTP security headers and HSTS cover the exact values scanners reward.

FAQ

Is Mozilla Observatory still available?

The HTTP scanning part lives on as the MDN HTTP Observatory and remains free. The original observatory.mozilla.org, including the TLS and SSH Observatories, was sunset in September 2024. Old scan history was preserved on MDN.

Does the MDN HTTP Observatory check TLS or certificates?

No. Mozilla's FAQ states the new tool focuses on HTTP data and that there are no plans to restore TLS or certificate analysis. Pair it with SSL Labs or a FortifyNet scan for that layer.

Is an A+ grade proof that a site is secure?

No. Mozilla itself is explicit on this point: header scanners test preventative configuration, not vulnerabilities such as outdated software, injectable forms or weak passwords. Treat an A+ as a strong baseline, not a certificate of security.

What is the best free Mozilla Observatory alternative?

For headers only, the MDN HTTP Observatory. For TLS, SSL Labs. If you want one scan that covers headers, TLS, DNS, email authentication and dark web exposure together, FortifyNet's free 60-second scan is the shortest path.

Check all six areas in one minute

The old Observatory taught the web that grades drive fixes. If you would rather not juggle three single-purpose scanners to rebuild it, run a free FortifyNet scan: headers, TLS, DNS, email authentication, dark web exposure and performance in about 60 seconds, no signup required.

Originally published at fortifynet.com/blog/mozilla-observatory-alternative. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

HTTP Security Headers: The Complete 2026 Guide with nginx & Apache Examples

Håkan Fägnell — Wed, 05 Aug 2026 09:22:30 +0000

Why Security Headers Matter

HTTP security headers are directives sent by your web server that instruct browsers on how to behave when displaying your website. Adding them requires no changes to your application code - only web server configuration - yet they are one of the most effective defenses against a wide range of common web attacks, including Cross-Site Scripting (XSS), clickjacking, and content injection.

Many websites neglect security headers entirely. A scan of the top million websites consistently shows that the majority are missing at least some critical headers. This is a missed opportunity because these headers are free and easy to add.

HSTS - HTTP Strict Transport Security

HSTS is a header that tells browsers: never connect to this website over plain HTTP, no matter what. Once a browser has seen an HSTS header from your site, it will automatically upgrade any future HTTP requests to HTTPS - even if the user types "http://" in the address bar or clicks an HTTP link. This is one of the most important security headers you can add.

The header has three important parameters. The "max-age" value tells the browser how long (in seconds) to remember this policy - you should set this to at least one year (31536000 seconds). The "includeSubDomains" flag extends this protection to all your subdomains. The "preload" flag tells browsers that you want to be included in the HSTS preload list - a list baked directly into Chrome, Firefox, and other browsers so that even the very first visit to your site is protected.

On nginx, you add this header with the add_header directive inside your server block. On Apache, you use the Header directive inside a VirtualHost block. Always include the "always" keyword to ensure the header is sent even with error responses.

Before setting a long max-age, make absolutely certain that your entire site - including all subdomains - is working correctly over HTTPS. Setting HSTS with a long max-age and then discovering that a subdomain does not support HTTPS can lock users out for months.

CSP - Content Security Policy

Content Security Policy is the most powerful security header available, and also the most complex to configure correctly. It tells browsers exactly which sources of content are permitted to load on your page - scripts, stylesheets, images, fonts, and more. This is your primary defense against Cross-Site Scripting (XSS) attacks, where an attacker manages to inject malicious JavaScript into your page.

A CSP works by whitelisting trusted sources. For example, you might specify that scripts can only be loaded from your own domain and from Google Analytics, that stylesheets can only come from your own domain, and that images can come from anywhere over HTTPS. Any content that does not match these rules is blocked by the browser before it can execute.

The most effective way to implement CSP is gradually. Start by adding a "Content-Security-Policy-Report-Only" header rather than "Content-Security-Policy." This means the policy is not enforced - violations are reported to you but the content still loads. This lets you collect violation reports, identify all the legitimate third-party resources your site actually loads, and build your policy without breaking anything. After a week or two of collecting data, switch to the enforcing version.

One common pitfall is "unsafe-inline" - a directive that allows inline scripts and styles. While this makes it easy to implement CSP without breaking your site, it dramatically reduces the protection it offers, because most XSS attacks rely on injecting inline scripts. A better approach is to use "nonces" or "hashes" to allow specific inline scripts while blocking injected ones.

X-Frame-Options

The X-Frame-Options header controls whether your website can be embedded inside an iframe on another domain. This protects against clickjacking attacks, where an attacker puts your website in an invisible iframe overlaid on top of their own page. The visitor thinks they are clicking something on the attacker's page but is actually clicking on your site - potentially authorizing a transaction, clicking an "accept" button, or performing some other action without realizing it.

The recommended value is "SAMEORIGIN," which allows your site to be embedded in iframes only from pages on your own domain. "DENY" prevents embedding entirely. The older "ALLOW-FROM" option is deprecated and not supported by modern browsers.

Note that if you have a modern CSP configured, you can use the "frame-ancestors" CSP directive instead of X-Frame-Options - it offers more fine-grained control. However, for maximum compatibility across all browsers, it is a good practice to include both.

X-Content-Type-Options

This simple but important header has a single value: "nosniff." It prevents browsers from "MIME sniffing" - guessing what type of content a file contains based on its actual content rather than the declared Content-Type header.

MIME sniffing sounds harmless but can be exploited. If an attacker can get you to host a file that looks like HTML or JavaScript to a browser's content sniffer - even if you think it is an image or text file - the browser might execute it as a script. Adding "nosniff" tells browsers to always respect the declared content type and never guess.

Referrer-Policy

When a user clicks a link from your website to another site, browsers automatically include a "Referer" header (note the misspelling - it is historical) telling the destination site where the user came from. This can inadvertently leak sensitive information if your URLs contain session tokens, search queries, or other private data in the query string.

The Referrer-Policy header controls what information is sent. The recommended value "strict-origin-when-cross-origin" sends the full URL for same-origin requests (useful for your own analytics) but only sends the domain (not the full URL) for cross-origin requests. This protects sensitive URL parameters while preserving useful referrer information for your own site.

Permissions-Policy

Permissions-Policy (formerly called Feature-Policy) controls which browser features and APIs your page is allowed to use. This includes potentially sensitive capabilities like the camera, microphone, geolocation, payment request API, and more. By explicitly disabling features you do not use, you prevent third-party scripts (advertising networks, analytics, embedded content) from accessing those features even if they try.

Frequently Asked Questions

Will adding a CSP break my website? It might, initially. CSP blocks anything not explicitly allowed. If you have inline scripts, inline styles, or third-party resources you have not whitelisted, they will be blocked. The solution is to use Report-Only mode first and spend time collecting violation reports before switching to enforcement.

What is the Server header and should I hide it? The Server header reveals your web server software and version - for example, "nginx/1.24.0." This information is useful to attackers who want to target known vulnerabilities in specific software versions. You should suppress or genericize this header. In nginx, set "server_tokens off." In Apache, use "ServerTokens Prod."

Do these headers affect site performance? Negligibly. The headers add a few bytes to each HTTP response but have no meaningful impact on load time. The security benefits far outweigh any marginal overhead.

Should I add security headers to HTTP responses as well as HTTPS? Yes - configure them on both, but remember that HSTS should only be sent over HTTPS. Sending HSTS over HTTP is ignored and could cause confusion.

Check Your Headers in 60 Seconds

You can verify every header in this guide by hand with curl, or let a scanner do the first pass. The free FortifyNet scan checks your security headers, SSL/TLS setup, DNS configuration, email authentication and dark-web exposure in about a minute, and tells you exactly what to fix first. No signup required.

Related guides

Originally published at fortifynet.com/blog/http-security-headers-guide. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here. Happy to answer questions in the comments.

Core Web Vitals 2026: Complete Google Ranking Guide

Håkan Fägnell — Tue, 04 Aug 2026 16:38:50 +0000

What Are Core Web Vitals?

Core Web Vitals are a set of specific metrics that Google uses to measure the real-world user experience of a web page. They focus on three aspects of the loading and interaction experience that research has shown are most important to users: how fast the main content loads, how quickly the page responds to user interactions, and how visually stable the page is during loading.

Google made Core Web Vitals an official ranking signal in 2021. What makes this significant is that the data comes from real Chrome users - not controlled laboratory conditions. Google collects field data through the Chrome User Experience Report (CrUX) and uses a 28-day rolling window. This means improvements you make today may take up to a month to fully show up in your ranking signals.

In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the interactivity metric. FID only measured the delay for the very first interaction a user made with a page. INP measures all interactions throughout the entire page lifecycle - every click, tap, and key press, and how quickly the page visually responds to each one. This makes INP a much more representative measure of how responsive your page feels.

LCP - Largest Contentful Paint

LCP measures how long it takes for the largest visible content element on the page to fully load. This is typically a hero image, a large heading, or a banner. Google considers an LCP under 2.5 seconds to be good, 2.5-4.0 seconds to need improvement, and above 4.0 seconds to be poor.

Why does this matter? Research consistently shows that users abandon pages that take too long to load. A one-second improvement in load time can increase conversions by 7-12%. The LCP metric tries to capture the moment when the user feels the page has "arrived" - when the main content is visible.

The most common causes of poor LCP are slow server response times, large uncompressed images, render-blocking JavaScript and CSS loaded in the document head, and lack of a content delivery network (CDN) to serve assets closer to users.

To improve LCP, the most impactful steps are usually: using modern image formats like WebP or AVIF instead of JPEG or PNG (typically 30-50% smaller files), adding explicit preload hints for your LCP element so the browser fetches it as early as possible, reducing server response time (TTFB) by enabling caching and using a CDN, and deferring any JavaScript that does not need to run before the page becomes visible.

INP - Interaction to Next Paint

INP measures the responsiveness of a page to user interactions. Specifically, it measures the time from when a user performs an input (click, tap, or key press) to when the browser next paints to the screen to show the visual result of that interaction. Google considers INP under 200 milliseconds to be good, 200-500ms to need improvement, and above 500ms to be poor.

High INP values feel like a sluggish, unresponsive page. When you click a button and nothing seems to happen for half a second, that is poor INP. This is particularly problematic for interactive applications - things like dropdown menus, filter controls, accordions, form validation, and any JavaScript-heavy interface.

The primary cause of high INP is long tasks on the browser's main thread. JavaScript is single-threaded, which means if one task takes a long time to execute, the browser cannot handle any user input or render any updates until it finishes. Tasks that take longer than 50 milliseconds are considered "long tasks" and are the biggest culprits.

To improve INP, focus on identifying and breaking up long JavaScript tasks. Use browser developer tools to find tasks that block the main thread. Defer non-critical work using techniques like setTimeout or requestIdleCallback. Minimize the impact of third-party scripts - every analytics tool, chat widget, and ad network you add runs JavaScript that competes for main thread time. Consider lazy-loading these scripts until after the page is interactive.

CLS - Cumulative Layout Shift

CLS measures visual stability - how much the page layout unexpectedly shifts while loading. If you have ever been about to click something and suddenly the page jumps and you accidentally click something else, that is a high-CLS experience. Google considers CLS under 0.1 to be good, 0.1-0.25 to need improvement, and above 0.25 to be poor.

The most common causes of layout shift are images and video embeds without declared dimensions (the browser does not know how much space to reserve until the file loads), ads and embeds that expand after loading, and dynamically injected content that pushes other content down.

The fix is usually straightforward: always declare width and height attributes on images and video elements. For responsive images, use CSS aspect-ratio instead. For ads and embeds, reserve their minimum expected size using CSS before they load. For web fonts, use font-display: swap to prevent invisible text, but pair it with font preloading to minimize the layout shift that occurs when the custom font replaces the fallback.

Why Field Data Differs From Lab Data

A common source of confusion is why Lighthouse scores and Search Console data show very different results. Lighthouse is a lab tool - it runs in a controlled environment on a simulated device with simulated network conditions. Search Console field data comes from real Chrome users with all their browser extensions, varying device capabilities, and real network conditions.

Your target users may be mostly on mobile devices with slower processors and cellular connections. Your Lighthouse score measured on a high-speed desktop connection does not reflect their experience. Always look at Search Console Core Web Vitals data - filtered by device type - to understand what real users are experiencing.

Frequently Asked Questions

How much does Core Web Vitals affect my Google ranking? Google describes it as a "tiebreaker" signal. When content quality and relevance are otherwise equal, better Core Web Vitals can give you an edge. For competitive keywords, it can make a meaningful difference.

My Lighthouse score is 90+ but Search Console shows poor field data. What is happening? Real users have slower devices, extensions that consume processing power, and real network conditions. Your lab score measures a best-case scenario. Prioritize fixing the field data issues that real users experience.

Does my JavaScript framework affect Core Web Vitals? Yes, significantly. Single-page applications built with frameworks like React or Angular often do all their rendering in JavaScript, which delays LCP (the page is blank until JS loads and executes). Server-side rendering (SSR) or static site generation (SSG) typically produces much better LCP scores.

How long do improvements take to show up in rankings? Google collects field data over a 28-day rolling window. Improvements may start appearing in Search Console within 2-4 weeks. Ranking changes typically lag behind by another 2-4 weeks.

Is it worth optimizing Core Web Vitals for my small website? Yes - not just for rankings but for user experience. Faster, more responsive websites have higher conversion rates, lower bounce rates, and better user satisfaction regardless of the SEO implications.

Originally published at fortifynet.com/blog/core-web-vitals-2026. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

DNS Security Configuration: SPF, DMARC, DNSSEC & CAA Explained

Håkan Fägnell — Sat, 25 Jul 2026 04:39:26 +0000

Why DNS Security is Critical

Your domain's DNS records are the foundation of your online presence. They tell the world where your website lives, where to deliver your email, and who is authorized to issue security certificates for your domain. When these records are poorly configured, attackers can exploit them in several devastating ways.

Email spoofing is one of the most common threats. Without proper DNS security, anyone in the world can send emails that appear to come from your domain. Your customers could receive phishing emails that look exactly like they are from you - requesting payment, asking them to click malicious links, or harvesting their credentials. This damages your reputation and exposes your customers to fraud.

DNS hijacking is another serious threat. An attacker who can modify your DNS records can redirect your visitors to a fake version of your website - capturing their logins and payment details before passing them on to the real site. The visitor may never notice anything is wrong.

The four pillars of DNS security - SPF, DKIM, DMARC, and DNSSEC - each address different aspects of these threats. Implementing all four gives you comprehensive protection.

SPF (Sender Policy Framework)

SPF is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server is on the approved list. If it is not, the email can be marked as suspicious or rejected outright.

Setting up SPF means adding a TXT record to your domain's DNS. The record starts with "v=spf1" followed by a list of authorized sending sources, and ends with a policy for what to do with unauthorized senders. Using "-all" means reject any email from a server not listed. Using "~all" means treat it as suspicious (soft fail). Never use "+all" which would allow anyone to send as your domain.

If you use Google Workspace for email, your SPF record should include Google's sending servers. If you use Microsoft 365, you include Microsoft's servers. If you use both plus a third-party service like Mailchimp for newsletters, you need to include all three. Keep in mind that SPF has a limit of 10 DNS lookups - if you use many services, this can become a challenge and you may need to optimize your record.

DKIM (DomainKeys Identified Mail)

DKIM takes email authentication a step further by adding a cryptographic digital signature to every outgoing email from your domain. Here is how it works: your email server signs each message using a private key that only you control. A corresponding public key is published in your DNS records. When a receiving mail server gets your email, it retrieves the public key from DNS and uses it to verify the signature. If the signature matches, the email is authentic and has not been tampered with. If it does not match, the email is likely a forgery.

DKIM is typically configured through your email provider's admin console - Google Workspace, Microsoft 365, and most email hosting providers have DKIM setup wizards. Once you enable DKIM in your provider's settings, they give you a DNS record to add. The record looks cryptic (it contains a long public key string) but you just need to add it to your DNS as directed.

The key benefit of DKIM beyond authentication is that it also protects email content integrity. A message signed with DKIM cannot be altered after signing without the signature becoming invalid. This means that even if someone intercepts your email in transit, they cannot modify its contents without detection.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC is the policy layer that sits on top of SPF and DKIM. It answers the question: "What should receiving mail servers do when an email claims to be from my domain but fails SPF or DKIM checks?" And equally importantly: "Can you please send me reports about what is happening with email sent from my domain?"

There are three DMARC policies. The first, "p=none," is monitoring-only mode. It does not block or flag any emails but instructs receiving servers to send you reports about what they see. This is where you should start - you may discover that legitimate senders (like your CRM, newsletter platform, or e-commerce system) are sending emails on your behalf that are not covered by your SPF or DKIM setup. Starting with monitoring gives you 2-4 weeks to identify and fix these before moving to enforcement.

The second policy, "p=quarantine," tells receiving servers to send emails that fail DMARC checks to the spam folder rather than the inbox. This is a good intermediate step - it reduces the impact of spoofed emails without risking that legitimate emails get rejected.

The third policy, "p=reject," is the gold standard. Emails that fail DMARC checks are rejected outright - they never reach the recipient's inbox. This is the most effective protection against email spoofing from your domain.

DMARC reports are XML files sent to the email address you specify in the record. They can be difficult to read in raw form, but free and paid tools exist to parse and visualize them in a human-readable way. These reports show you every IP address that is sending email claiming to be from your domain, whether those emails pass SPF and DKIM, and how many there are.

DNSSEC (DNS Security Extensions)

DNSSEC addresses a different attack vector: the DNS system itself. When your browser looks up the IP address of a website, it sends queries to DNS servers. Normally there is no way to verify that the answer you receive is legitimate - an attacker positioned between you and the DNS server could return a fake IP address pointing to a malicious site. This is called DNS cache poisoning.

DNSSEC solves this by adding cryptographic signatures to DNS records. When a DNS resolver returns an answer, it includes a signature that can be verified using a chain of trust anchored at the root DNS zone. If the signature does not match, the resolver knows the answer has been tampered with and rejects it.

DNSSEC is enabled at your domain registrar - the company where you registered your domain. Most major registrars support DNSSEC. The process typically involves going to your domain settings, finding the DNSSEC option, and enabling it. The registrar handles the cryptographic key generation. After enabling, allow 24-72 hours for propagation and verify it is working using an online DNSSEC testing tool.

CAA (Certification Authority Authorization)

CAA records are a simple but powerful protection against unauthorized SSL certificate issuance. Without CAA records, any of the hundreds of Certificate Authorities in the world could potentially issue a certificate for your domain - either through an error or as a result of being compromised. A fake certificate issued for your domain could be used in a man-in-the-middle attack against your visitors.

CAA records let you specify exactly which CAs are authorized to issue certificates for your domain. For example, if you use Let's Encrypt for all your certificates, you can add a CAA record that only permits Let's Encrypt to issue certificates. Any other CA that receives a certificate signing request for your domain will see this record and refuse.

You can also include an iodef record that specifies an email address where CAs should send notifications if they receive an unauthorized certificate request for your domain - giving you early warning of potential attacks.

Frequently Asked Questions

Do I need all four: SPF, DKIM, DMARC, and DNSSEC? Yes, because they protect against different threats. SPF and DKIM authenticate your email. DMARC enforces that authentication and provides visibility through reporting. DNSSEC protects the integrity of your DNS records themselves. Each layer adds protection the others do not provide.

My DMARC is set to p=none. Am I protected? No. p=none is monitoring mode only. It does not block or flag any spoofed emails. It just tells receiving servers to send you reports. You need p=quarantine or p=reject to actually prevent spoofed emails from reaching inboxes.

Can I have multiple SPF records? No - only one SPF TXT record is allowed per domain. If you have multiple, most email servers will fail the SPF check entirely. Combine all your sending sources into a single record.

How long does DNS propagation take? DNS changes typically propagate within 1-48 hours globally. The exact time depends on your DNS record's Time To Live (TTL) setting. If you set a low TTL before making changes, propagation can happen within minutes.

What is a dangling DNS record and why is it dangerous? A dangling record is one that points to a resource that no longer exists - for example, a subdomain pointing to a cloud service you have cancelled. Attackers can register or take over that orphaned resource and use it to serve malicious content that appears to come from your legitimate domain.

Originally published at fortifynet.com/blog/dns-security-configuration. I'm the founder of FortifyNet, a website security scanner; this guide comes from our blog, and every DNS check described here can be done by hand with dig or nslookup, no tool required.