Home / Articles / HTTPS and Security Headers on Free Static Hosts:…

HTTPS and Security Headers on Free Static Hosts: A Practical Baseline

1 Oct 2026 · ~10 min · security

Static sites still deserve a security baseline. You may not run a database, but you do terminate HTTPS, load third-party scripts (eventually ads), and ask users for trust via contact forms. This guide covers a practical header and HTTPS checklist for free static hosts—especially Cloudflare Pages—without breaking your own CSS or future AdSense units.

HTTPS is non-negotiable

AdSense and modern browsers expect HTTPS. On Pages, *.pages.dev includes certificates automatically. Custom domains get certificates after DNS validates. Do not submit mixed-content pages (HTTP assets on HTTPS pages). Use root-relative or HTTPS absolute URLs for stylesheets and images.

Redirect HTTP to HTTPS at the edge when the platform offers it—Cloudflare usually handles this when the hostname is active on their network. Confirm with curl -I.

Useful headers

• X-Content-Type-Options: nosniff — reduces MIME confusion attacks.
• Referrer-Policy: strict-origin-when-cross-origin — sensible default for content sites.
• Permissions-Policy — disable unneeded browser features (camera, mic) explicitly.
• X-Frame-Options: DENY or CSP frame-ancestors — clickjacking resistance (ensure you do not need embedding).

HSTS can wait until you are sure the custom domain is stable—locking HTTPS on a hostname you might abandon complicates cleanups. When ready, enable carefully with modest max-age first.

CSP without painting yourself in

Content-Security-Policy is powerful and easy to misconfigure. A tiny static blog can start without a strict CSP, then add a report-only policy while testing. When AdSense arrives, you will need to allow Google’s script origins—budget time for that rather than shipping a CSP that blocks ads or your own CSS on day one.

Never copy a CSP from a random gist without understanding every directive. Broken CSP presents as “my site has no styles” which looks unprofessional during review.

Cloudflare Pages specifics

You can add a _headers file in the publish directory (when supported for your project type) or configure Transform Rules / Headers in the dashboard if the zone is on Cloudflare. For CNAME setups where DNS remains on DNSHE, some zone-level Cloudflare features may be limited; prefer publish-directory headers or Pages-native configuration where available.

Test headers with:

curl -I https://negency-lab-pilot.pages.dev/

Compare responses on a sample article path too—some misconfigurations only hit nested routes.

Contact forms and spam

A mailto: link is acceptable for early pilots and avoids storing messages. If you add a form endpoint (Workers, Formspree, etc.), rate-limit, consider CAPTCHA/Turnstile, and never log secrets. Mention the form processor in your privacy policy. For AdSense review, a working contact method matters more than a fancy CRM.

Baseline checklist

• HTTPS green on pages.dev and any custom domain
• No mixed content
• nosniff + referrer-policy set
• No accidental directory listings of sensitive files (do not upload them)
• Dependencies/scripts inventoried before AdSense
• Privacy policy mentions hosts and future ads

Security on a static pilot is mostly hygiene. Do the basics well; skip theater that breaks publishing speed.

Supply chain basics for static pages

Even without npm in production, your authoring machine has a supply chain. Pin tool versions when you generate HTML. Avoid copy-pasting JavaScript widgets from untrusted “hit counter” sites. When you eventually load AdSense, you are explicitly trusting Google’s script origins—do that via official docs, not third-party “optimized ad snippets.”

Subresource Integrity (SRI) helps for third-party static libraries you self-host or lock. For frequently changing ad scripts, SRI is often impractical—another reason to keep the pre-approval site free of random CDNs.

Secret scanning before upload

Before every deploy, scan the publish directory:

grep -R -E 'API_TOKEN|apikey|BEGIN (RSA |OPENSSH )?PRIVATE|password\s*=' . || true

Adjust patterns for your stack. Fail the deploy if matches appear in HTML or JS. Teach every collaborator that screenshots of token dashboards are radioactive—do not leave them in the web root “for later.”

Cloudflare API tokens belong in environment variables on the build machine only. Gmail passwords belong in a password manager, never in site files or shared Drive docs.

Example _headers snippet

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  X-Frame-Options: DENY

Confirm your host honors _headers for your project type. If not, set equivalent rules in the dashboard or defer until custom domain architecture is clear. A missing header file is better than a wrong CSP that blanks the site.

Re-test after enabling ads: ad iframes and scripts may require relaxing frame or script policies thoughtfully.

If something leaks

Suppose a token is uploaded by mistake. Remove it from the publish directory, redeploy immediately, revoke the token in the Cloudflare dashboard, issue a replacement with least privilege, update local secrets files, and check whether the token appeared in public caches or chat logs. Treat HTML source and Wayback-style archives as potentially sticky. Document the incident privately; do not put the revoked secret into the public postmortem page.

Good security on a static pilot is mostly prevention and fast rotation—not a SOC dashboard.