Essential Cloudflare Security Settings Before Publishing a Website

When building a new website, it is natural to check its appearance and features first. Before publishing it, however, I also need to ask which files can be accessed from the internet, whether HTTP requests are redirected securely, and whether basic response headers are in place.

When operating several sites on Cloudflare, it is easier to define a common deployment and security checklist than to rediscover the same settings for every project.

1. Separate public website files first

A private GitHub repository does not make deployed static assets private. If the static-assets directory points at the entire repository root, development documents and configuration files may become part of the public deployment.

For example, this configuration requires particular care:

{
  "assets": {
    "directory": "."
  }
}

Where possible, prepare a dedicated public/ or dist/ folder containing only the HTML, CSS, JavaScript, images, and other files intended to be served.

{
  "assets": {
    "directory": "./public"
  }
}

The important boundary is not the folder's name, but the build process that limits what enters it. Copy or generate only the required public files, and exclude internal documents, credentials, and development-only settings.

.gitignore controls what Git tracks; it is not a mechanism for hiding a file from a deployed website.

Check the Cloudflare Git build command

If your repository builds a dedicated public directory, Cloudflare's connected build must actually run that preparation step. A project using Node.js and Wrangler might use:

Build command  : npm run build
Deploy command : npx wrangler deploy

Verify that the build script in package.json creates the expected assets and that assets.directory in wrangler.jsonc points to the finished output. Commands vary across frameworks and deployment types.

The Deploy command above is an example of a command configured inside Cloudflare's Git-integrated build environment, not an instruction to deploy manually from a local PC. ONSEMO builds and checks locally, pushes to GitHub, then lets Cloudflare's Git integration deploy.

2. Redirect HTTP access to HTTPS

Having a working HTTPS URL is not the same thing as automatically redirecting HTTP traffic to it.

In Cloudflare, check this path:

1. Select the domain zone in the Cloudflare dashboard.
2. Open SSL/TLS → Edge Certificates.
3. Enable Always Use HTTPS.
4. Verify that an HTTP request actually redirects to HTTPS.

Before enabling this option, confirm that the destination hostname has a valid HTTPS certificate and that existing redirects work correctly.

The setting applies to eligible requests handled through the selected Cloudflare zone's proxy. Do not assume it protects every DNS-only record or a separate host that is not passing through that zone.

Reference: Cloudflare — Always Use HTTPS

3. Configure common response security headers

HTTPS alone does not control how a browser interprets content types or transmits referring URLs. Two useful initial headers are:

A corresponding Cloudflare dashboard path is:

Rules → Overview → Create rule → Response Header Transform Rule

Select the relevant requests and use Modify response header with Set static for each header name and value. You can use Set new header for another entry.

To apply the same policy to multiple subdomains in a zone, you may consider All incoming requests. But this means the eligible requests within that Cloudflare zone; it does not automatically include every separate Cloudflare project or workers.dev URL.

Since these rules may override existing headers, check whether particular services require exceptions.

Reference: Cloudflare — Response Header Transform Rules

4. Verify actual responses, not only dashboard settings

Saving a dashboard configuration does not by itself prove that the browser receives the expected response. Send read-only requests to representative URLs.

# Verify that an HTTP request goes to HTTPS.
curl -sS -D - -o /dev/null "http://example.com/"

# Inspect HTTPS response headers.
curl -sS -D - -o /dev/null "https://example.com/"

For HTTP, check the appropriate redirect status—often 301—and the HTTPS Location. For HTTPS, inspect the resulting X-Content-Type-Options and Referrer-Policy headers.

Also check static assets, public API routes, downloads, and other representative service paths. Make sure caching, CORS, authentication, and download behavior have not changed unexpectedly.

Independently check the published file boundary: representative internal document paths should not return their original contents. Testing a handful of paths does not prove that every sensitive file is inaccessible.

5. Apply additional protections according to the service

These controls deserve consideration, but should not all be switched on with identical settings without review:

• HSTS: Enable only after HTTPS works reliably and you have examined the relevant subdomains. Carefully consider includeSubDomains and preload.
• CSP: Inventory script, style, and external resource dependencies first. Content-Security-Policy-Report-Only can help identify potential breakage before enforcement.
• Preview: Determine whether Preview URLs are publicly accessible and whether drafts or production data might be exposed.
• Other hostnames: Custom domains and default workers.dev hosts can be subject to different policies. Consider compatibility before changing endpoints still used by clients.

Reference: Cloudflare — HSTS

A pre-deployment checklist

Checking these together at the start of a project reduces the chance of repeating the same mistakes later.

Security is not just changing settings. It includes understanding exactly what is public and checking what the real server returns.

Official references

• Cloudflare — Always Use HTTPS
• Cloudflare — Response Header Transform Rules
• Cloudflare — HSTS