Defaults.Exposed › Fixes › CDN / WAF & hosting

How to fix CDN / WAF & hosting

Updated 17 October 2026, figures from the October 2026 census, snapshot 2026-10-12.

Two reads of the plumbing behind your website: whether you sit behind a protective shield (a CDN with a Web Application Firewall, like Cloudflare) that filters attacks and absorbs traffic spikes, and a map of who runs your DNS (Domain Name System), website and email. Both are informational on our scoring and do not move your grade. They do describe how exposed your origin server is to attack and outage, and how tangled your providers are.

The census does not grade hosting choices, and it does record what a stack announces about itself. Of the 332,492,319 domain records in the census's HTTP (Hypertext Transfer Protocol) pass, a base that includes domains that sent no response, 220,432,333 named their server software and 25,795,041 also named the application layer in X-Powered-By.

Counted over the published stack-headers export, /data/stack-headers.json, which counts raw response headers across the edition.

A website with no shield in front of it takes every attack and every traffic spike directly on the origin server, so a bot flood, a launch-day surge, or a single automated attack can knock you offline for hours, and recovery is on you. Putting a CDN/WAF in front (free tier available) filters the vast majority of automated attacks, soaks up surges, and speeds the site up worldwide, typically an afternoon's work for your IT person, at no licence cost. Separately, if your DNS, website and email all live with one provider, a single outage or breach there takes your entire online presence down at once; knowing your provider map is the first thing you need in an incident.

Why CDN / WAF & hosting matters

Both checks here are informational on our methodology: they're registered with zero points and never change your grade, because they describe your infrastructure rather than test a pass/fail security control. A site with no CDN/WAF takes every attack and traffic spike on the origin directly, with no filtering and no surge absorption; adding one is cheap, and Cloudflare's free tier is the common route. And a clear provider map (knowing whether your DNS, web and email are split or stacked on one provider) is the first thing you need when something goes wrong.

What the infrastructure check is, in plain words

Every website runs on a server somewhere. The question this page answers is: what stands between the open internet and that server, and who runs the pieces of your online presence?

There are two parts:

CDN / WAF: the shield in front. A CDN (Content Delivery Network) is a global network that sits in front of your site, serves your content fast to visitors anywhere, and soaks up traffic surges. A WAF (Web Application Firewall) is a filter that inspects incoming requests and blocks the malicious ones before they reach your server. The popular services (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri, and others) bundle these together. We look at your site’s responses and report whether we can see a shield in front, and we note what web server you’re running, too.
Hosting / provider map: who runs your plumbing. We read the public records that say who handles your DNS (the directory that turns your domain into an address), and who handles your email. From that we can tell whether your DNS, website and email are split across providers (resilient) or stacked on one (convenient, but a single point of failure).

What this can cost you

These are the everyday ways an unshielded, tangled setup turns a small problem into a bad day.

Your site sits on the origin server with nothing in front of it. On the morning of a launch or a promotion, traffic spikes, or a modest bot flood hits, and the server can’t cope. Pages time out, the checkout errors, and you lose the day’s revenue while your host firefights. A CDN absorbs surges and a WAF filters the junk traffic before either reaches the server.
Your DNS, website and email all run through a single provider. When that provider has an outage (it happens to all of them eventually), your site, booking system and email all go down with it. You can’t process orders, and you can’t email customers about the outage because the mailbox is down too. Splitting providers keeps one provider’s failure from taking the others down with it.
With no WAF, every automated probe (injection attempts, login-guessing, known-exploit scanners) hits your application code with no filtering. You’re betting that your software is flawless and fully patched, forever. A WAF blocks the overwhelming majority of that automated noise before it reaches you.
Something breaks and the first hour is wasted on “wait, who runs our DNS? Is email on the same host? Who do we call?” When your provider map is unclear, every incident starts from zero.
A prospect’s IT team scans you before signing and sees a bare origin with no CDN/WAF, and a server header openly advertising your exact software and version. It’s a small signal, but it lands you in the “haven’t hardened the basics” column at exactly the wrong moment.

The two layers, and who runs each

CDN / WAF: the protective layer

When a visitor (or an attacker) requests your site, the request can either go straight to your origin server, or it can go through a CDN/WAF first. If there’s a shield in front, that shield can:

Filter malicious requests (the WAF part): block injection attempts, bot attacks, and known exploit patterns before they ever reach your code.
Absorb traffic (the CDN part): serve cached content from servers near each visitor and soak up surges, so a spike, legitimate or hostile, doesn’t crush your origin.
Speed the site up: content delivered from a nearby edge server loads faster for visitors worldwide.

We detect a shield by looking at the fingerprints these services leave in your site’s response headers, for example a cf-ray header (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai), or x-sucuri-id (Sucuri). We also read the Server header to identify your underlying web server (nginx, Apache, IIS, LiteSpeed, Caddy, and so on), and flag any X-Powered-By header that’s over-sharing.

What “good” looks like: a CDN/WAF detected in front of your origin, and a Server header that does not advertise a specific version number.

Hosting / provider map: your infrastructure dependencies

Your domain points to several different services:

DNS. The directory that turns yourbusiness.com into the actual server address. We read your nameserver (NS) records and recognise common providers (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode, and regional registrars among them).
Email. Where your mail is handled. We read your MX (Mail Exchange) records and recognise common providers (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho, and others).

From this we can see whether these responsibilities are split across providers (a failure in one doesn’t take down the others) or stacked on a single provider (convenient, but one outage or breach takes everything).

What “good” looks like: at minimum, DNS held by a dedicated, reliable provider rather than bundled into the same account as everything else, so your domain’s directory doesn’t share fate with your website and inbox.

How to fix it (free, ~1 afternoon)

Hand this to your IT person or web developer: the fix is free. Putting a CDN/WAF in front of your site costs nothing on the common free tiers, and suppressing your server version is a one-line setting. There’s no licence to buy. (Paid options here are only monitoring, portfolio tracking and audits, never the fix itself.) The owner’s only decision is: yes, put a shield in front of the site.

1. Put a CDN/WAF in front of your site

The most common, free route is Cloudflare:

Create a free Cloudflare account and add your domain.
Cloudflare reads your existing DNS records; check they imported correctly.
Change your domain’s nameservers (at your registrar) to the two Cloudflare gives you. This is the switch that routes traffic through Cloudflare.
Set SSL/TLS mode to Full (strict) so encryption stays end-to-end between visitor → Cloudflare → your origin. (Avoid “Flexible,” which leaves the last leg unencrypted.)
The CDN and a baseline WAF are now active. You can tune WAF rules later, but the defaults already filter a lot.

Other routes, depending on your stack:

AWS CloudFront. Create a distribution pointing at your origin; pair with AWS WAF for filtering. Best if you’re already on AWS.
Sucuri WAF. DNS-based, requires no changes on your server; good if you can’t touch the origin.
Fastly / Akamai. Enterprise-grade CDNs/WAFs, typically for larger or higher-traffic sites.

After switching, test the site, confirm HTTPS (Hypertext Transfer Protocol Secure) works everywhere, and watch it for a day. Don’t aggressively cache pages that must stay personal or live (logged-in areas, baskets, checkouts).

2. Stop advertising your server version

Whether or not you add a CDN, suppress the version your server announces. It’s free information you’re handing attackers.

Nginx:

server_tokens off;

Apache (in the main config):

ServerTokens Prod
ServerSignature Off

Remove an over-sharing X-Powered-By header (e.g. from PHP or an app framework) at the server or CDN level. On Cloudflare you can strip it with a response-header transform rule.

3. Sanity-check your provider map (optional, ~10 minutes)

Look at where your DNS, website and email live:

If all three sit in one provider account, consider at least moving DNS to a dedicated provider (Cloudflare DNS is free and fast). That single split means your domain’s directory survives a hosting outage.
Write the map down: DNS provider, web host, email provider, registrar, and the login/support contact for each. This one page is the most useful thing you can have in front of you during an incident.

Platform notes

Google Workspace / Microsoft 365: these are your email providers and don’t run your website. Putting a CDN/WAF in front of the website doesn’t touch email, and vice versa; they’re separate decisions. (Having email on Google/Microsoft and the website behind Cloudflare is a perfectly good, deliberately-split setup.)
Managed site builders (Wix, Squarespace, Shopify): these include their own CDN and a level of WAF protection as part of the platform, so you may already be shielded even if our header check doesn’t name a provider. You usually can’t add your own Cloudflare in front; that’s fine, because the platform handles it.
WordPress on your own hosting: ideal candidate for a free Cloudflare layer in front. Combine it with a security plugin’s firewall for application-level rules.

Common mistakes

Running a bare origin “because the site is small.” Small sites get hit by the same automated attacks and bot floods as big ones: the bots don’t check your revenue first. The free CDN/WAF tier exists precisely for small sites; not using it is leaving an easy win on the table.
Using Cloudflare “Flexible” SSL (Secure Sockets Layer). It shows a padlock but leaves the connection between Cloudflare and your origin unencrypted. Always use Full (strict) so it’s encrypted end to end.
Caching the wrong things. Aggressively caching logged-in pages, baskets or checkouts can show one customer another’s content or stale prices. Cache static content; leave personalised and transactional pages uncached.
Stacking everything on one provider without realising it. Convenience is fine if it’s a conscious choice, but many businesses only discover DNS, web and email share one account during the outage that takes all three down.
Leaving the server version on display. It’s a free, one-line hardening step that’s easy to forget. Turn it off.

A note on grade

We never penalise you for an unshielded origin or a single-provider setup. If you put a shield in front of your site and split your DNS off, you’ve made the business more resilient for free.

Questions people ask

These don't affect my grade, so why should I care?

Because the grade measures specific security controls (encryption, email anti-spoofing, security headers), while these two checks describe your resilience: how exposed you are to downtime and attack. A bare server with no shield can still score well on the graded checks and still get knocked offline by a bot flood on launch day. A CDN/WAF improves that resilience whatever your grade, and the common route is free.

I'm not technical. What do I need to do?

One decision and one hand-off. The decision: do you want a protective shield (CDN/WAF) in front of your site? For almost every business the answer is yes, and the common route (Cloudflare's free tier) costs nothing. The hand-off: give the 'How to fix it' section to whoever manages your website or domain. Setting up a free CDN/WAF is typically an afternoon's work and there's no licence fee. The fix is free; only optional monitoring and portfolio tools are paid.

What's the difference between a CDN and a WAF? Do I need both?

A CDN (Content Delivery Network) is a global network of servers that sits in front of your site, caches your content close to visitors so pages load faster, and absorbs traffic spikes so a surge doesn't crush your origin. A WAF (Web Application Firewall) is a filtering layer that inspects incoming requests and blocks malicious ones (injection attempts, bot attacks, known exploit patterns) before they reach your server. The good news is the popular services bundle both: turn on Cloudflare (or similar) and you get the CDN and a baseline WAF together.

Is it bad that all my services are with one provider?

It's a concentration risk. A single provider gives you a single bill, login and support line, but one outage or one account compromise can take your DNS, website and email down together, and leave you unable to even communicate about it. Many small businesses accept this consciously. The point of the check is simply to make the dependency visible so you can decide whether to accept it. A common, low-effort improvement is to move DNS to a dedicated provider (Cloudflare's DNS is free), so at least your domain's directory doesn't share fate with your hosting.

We detected your server software and version. Why does that matter?

When your server advertises exactly what software it runs and which version (in the 'Server' or 'X-Powered-By' header), it hands attackers a shortcut: they can look up known vulnerabilities for that exact version and aim straight at them. It doesn't make you insecure on its own, but it's needless information disclosure, like leaving the make and model of your locks on the front door. Suppressing the version (a one-line server setting, free) is a small, sensible hardening step. It's covered in the fix steps below.

Will putting a CDN in front of my site break anything or slow it down?

Done correctly, it speeds the site up. That's the whole point of a CDN. The main things to get right during setup are: make sure HTTPS stays end-to-end (use 'Full (strict)' mode on Cloudflare rather than 'Flexible'), and don't aggressively cache pages that need to be personal or live (logged-in dashboards, checkouts). Reputable providers default to sensible settings. Test the site after switching the nameservers over and watch it for a day.

Figures as of 12 October 2026, from the October 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.