Defaults.Exposed › Fixes › CDN / WAF & hosting

How to fix CDN / WAF & hosting

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 actually runs your DNS, website and email. Both are informational on our scoring — they do not move your grade — but they describe how exposed your origin server is to attack and outage, and how tangled your providers are. A shield in front and a sensibly split set of providers is what resilient businesses look like.

Bottom line for your business: 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. Neither check changes your grade — but both describe real exposure to downtime, lost sales and a slow, painful recovery.

What this can cost you

• A burst of bot traffic or a small DDoS hits your unshielded server on the morning of a big promotion — the site crawls or falls over, customers get errors at the checkout, and you lose the day's sales while your host scrambles. A CDN/WAF in front would have absorbed it.
• Your DNS, website and email all run through one provider; that provider has an outage and your site, your booking system AND your email all go dark at the same moment — you can't even send 'we're aware of the issue' because the mailbox is down too.
• An automated attack probes your site all night — SQL injection and login-guessing scripts hammering your origin directly because there's no firewall layer to filter them — and you only find out when something breaks. A WAF blocks the bulk of that noise before it ever reaches your code.
• An incident hits and nobody can answer the basic question 'who do we even call?' — is the website on the same host as email? Who runs the DNS? Hours bleed away just mapping the plumbing while the site stays down.
• A prospect's IT team scans you before signing and sees a bare origin server with no CDN/WAF and a leaky server-version header advertising exactly what software (and version) you run — a small 'these people haven't hardened the basics' signal at the worst possible moment.

Why it 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. We surface them because they map real business exposure. 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 (Cloudflare's free tier is the common route) is one of the highest-leverage, lowest-cost resilience upgrades a small business can make. 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 and the difference between a contained incident and a total blackout.

What this 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 actually runs the pieces of your online presence?

There are two parts:

1. 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.

2. 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).

The most important thing to know up front: on our scoring, both of these are informational. They do not affect your grade. We surface them because they describe how exposed your business is to downtime and attack — which is a different, and very practical, question from the grade.

What this can cost you

These aren’t abstract risks — they’re the everyday ways an unshielded, tangled setup turns a small problem into a bad day.

• Knocked offline on the day it matters most. 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; together they’re the difference between “busy day” and “down all morning.”

• Everything goes dark at once. Your DNS, website and email all run through a single provider. That provider has an outage (it happens to all of them eventually) and your site, your booking system and your email vanish simultaneously. You can’t process orders, and you can’t even email customers to say you’re aware — because the mailbox is down too. Splitting providers means one failure is contained, not total.

• Your code takes every attack directly. 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, turning “constant background attack” into “mostly filtered.”

• A slow, panicked incident because nobody has the map. 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. Knowing the map up front turns a scramble into a phone call.

• A bad first impression to a careful buyer. 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.

What it actually is

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 quietly 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 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.

Because both checks are informational, none of this is graded — but a CDN/WAF is one of the highest-value resilience upgrades a small business can make, so it’s worth doing.

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

The most common, free route is Cloudflare:

1. Create a free Cloudflare account and add your domain.
2. Cloudflare reads your existing DNS records; check they imported correctly.
3. Change your domain’s nameservers (at your registrar) to the two Cloudflare gives you. This is the switch that routes traffic through Cloudflare.
4. 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.)
5. 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 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 actually 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, not 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 — 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. 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. Make it a decision, not a discovery.
• 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

To be completely plain: neither of these checks affects your grade. They’re registered in our methodology as informational, with zero points, and we never penalise you for an unshielded origin or a single-provider setup. We report them because they describe real exposure to downtime, attack and slow incident recovery — and because adding a free CDN/WAF is one of the best-value upgrades a small business can make. If you do nothing here, your grade is unchanged. If you put a shield in front of your site and split your DNS off, you’ve made the business meaningfully more resilient for free. That’s the right way to read this page: not a number to defend, but a resilience upgrade worth taking.

FAQ