RemedyProof
Sign Up

Cloudflare security settings

Cloudflare security settings audit: what to verify

Start with the Cloudflare dashboard settings, then verify the public behavior they are meant to produce. A useful audit checks DNS authority, Always Use HTTPS, Minimum TLS, and HSTS separately because a saved setting is not the same as an observed result.

Get started freeSee capabilities and limits

The four checks that matter

  • DNS authority: confirm the intended zone and records are managed in the authoritative Cloudflare account. A screenshot of a record in a dashboard does not prove which nameservers answer publicly.
  • Always Use HTTPS: confirm the Cloudflare setting is enabled, then request the HTTP hostname and verify that it redirects to HTTPS.
  • Minimum TLS: record the configured minimum and separately verify that older TLS versions are rejected at the public edge.
  • HSTS: review the header values served over HTTPS. Treat max-age, includeSubDomains, and preload as separate rollout decisions.

Stage HSTS deliberately

Use 15,552,000 seconds as the current HSTS max-age baseline for the reviewed remediation pack. Before enabling includeSubDomains or preload, prove that HTTPS works for every covered subdomain and that no legacy HTTP dependency remains. HSTS can make a browser refuse HTTP recovery paths, so it should follow public verification rather than lead it.

The Cloudflare dashboard is useful evidence of intended configuration. The public response is evidence of what a visitor received. Keep both when explaining a change to a client.

What a bounded audit can say

A point-in-time audit can say which authorized hostname was checked, what deterministic rules observed, and whether a later same-rule check changed. It cannot say a website is secure, certified, compliant, or penetration-tested. RemedyProof’s free Public Snapshot is a one-time read-only baseline retained for seven days; it does not enable recurring monitoring.