What we checked
• 19 sites, October 2026: 12 independent inns, B&Bs and restaurants in the USA, 7 developer and small-studio sites in the USA and India.
• Passive only: one normal GET of the home page each. DNS, IP ranges, response headers, cookies. No attack-looking probe on these sites.
• Tool: the same checks as the osec.one site protection scan, minus the probe.
• No names: the numbers below are totals, not a list of sites.
The numbers
• 13 of 19 (68%) showed no firewall (WAF) in front.
• 6 of 19 did: 5 behind Cloudflare, 1 with the Wordfence plugin on WordPress.
• Inns and restaurants: 8 of 12 with no firewall seen.
• Developer sites: 5 of 7 with no firewall seen; 4 of those 5 sit behind a CDN or host edge (2 Vercel, 2 CloudFront) with no WAF signs.
Security headers on the same 19 home pages
• Strict-Transport-Security (HSTS): 10 of 19.
• X-Content-Type-Options: 10 of 19.
• X-Frame-Options: 7 of 19.
• Content-Security-Policy: 4 of 19.
• Referrer-Policy: 4 of 19.
• Permissions-Policy: 2 of 19.
• None of the six: 5 of 19.
• All six: 1 of 19 (a Cloudflare site with its own headers set).
• Software version in the Server header: 2 of 19 (an nginx build and gunicorn 19.9.0, released in 2018).
Where the 13 sites with no firewall live
• Hosted site builders (4): Duda (2), SpotOn (1), Squarespace (1). Nothing to install; the builder's own platform protection is what you get.
• Shared Apache hosting (3): plain HTML or PHP sites. No server config access, so no reverse proxy rules.
• Self-hosted WordPress (2): one on nginx, one on Apache with a caching plugin; neither showed a security plugin.
• Vercel (2): Vercel's platform firewall and DDoS mitigation are always on; we saw no custom WAF signs.
• CloudFront (2): a CDN in front, no AWS WAF signs (AWS WAF is a separate service you attach to a distribution).
What each kind of site can do
1. WordPress: a security plugin (Wordfence, or the osec.one plugin) stops login guessing and scans for old plugin files before they reach PHP.
2. Your own server (nginx, Caddy, Traefik, Apache): an auth check in front of the app. With nginx it's one auth_request line; no DNS change.
3. Node or Python app: a middleware that asks before each request (Express, FastAPI).
4. CloudFront: attach AWS WAF to the distribution, or check at the origin.
5. Vercel: add custom WAF rules and rate limits in the Vercel Firewall.
6. Site builders and shared hosting: ask the host what they block; moving the DNS behind a proxy is the only extra layer.
Quick wins that cost nothing
• Add HSTS once every page works over HTTPS.
• Add X-Content-Type-Options: nosniff and frame-ancestors 'self' (or X-Frame-Options) so another site can't frame your pages.
• Hide version numbers in the Server header.
• Rate-limit the login page and block requests for .env, .git and wp-login.php floods.
• Re-scan after each change to see it from outside.
Check your own site
1. Open https://osec.one/tools/site-protection.
2. Type your domain.
3. Read the firewall line, the probe result and the headers lines.
4. No firewall seen? The result links the no-DNS options for your kind of host.
See what sits in front of your site, in a minute.
Run the site protection scanLimits of this data
• Small sample: 19 sites from our own lists, not a random survey.
• Passive: a firewall that only acts on attack traffic can be invisible to one normal GET.
• Home page only: other pages may send other headers.
Sources
• OWASP Secure Headers Project: https://owasp.org/www-project-secure-headers/
• MDN, Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
• WordPress, brute force attacks: https://wordpress.org/documentation/article/brute-force-attacks/
• nginx, auth_request module: https://nginx.org/en/docs/http/ngx_http_auth_request_module.html