Cloudflare Setup Guide – Security Headers for comfytechcheck.com

GitHub Pages does not support custom HTTP response headers. Since comfytechcheck.com is hosted on GitHub Pages but proxied through Cloudflare, security headers must be added at the Cloudflare edge.

Two Methods

Since this site uses GitHub Pages + Cloudflare proxy (not Cloudflare Pages), use Method A.

Method A: Cloudflare Transform Rules (Recommended)

Step 1 – Log into Cloudflare Dashboard

1. Go to https://dash.cloudflare.com
2. Select the domain comfytechcheck.com

Step 2 – Create an HTTP Response Header Modification Rule

1. Navigate to Rules → Transform Rules
2. Click the Modify Response Headers tab
3. Click Create Rule
4. Give the rule a name: Security Headers -- comfytechcheck.com

Step 3 – Set the Rule Criteria

• When: Hostname equals comfytechcheck.com
• And: (leave all other fields empty to match all requests)

Step 4 – Add Each Header

Click Add new header for each of the following:

Important: Set the Action dropdown to Set static value for each header. Do not use “Remove” or “Dynamic”.

Step 5 – Save and Deploy

1. Click Save
2. The rule becomes active within seconds

Header Details

1. Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Forces all communication over HTTPS for 1 year
• includeSubDomains covers all subdomains
• preload allows inclusion in browser HSTS preload lists

2. X-Content-Type-Options

X-Content-Type-Options: nosniff

• Prevents MIME-type sniffing by browsers

3. X-Frame-Options

X-Frame-Options: DENY

• Prevents clickjacking by blocking the site from being loaded in frames

4. Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

• Sends full URL as referrer for same-origin requests
• Sends only origin for cross-origin requests
• Sends no referrer when downgrading from HTTPS to HTTP

5. Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

• Restricts resources to same origin
• Allows inline styles (needed for Jekyll)
• Allows data: URIs for images
• Blocks framing (frame-ancestors 'none')
• Restricts form submissions to same origin
• Note: If you add third-party scripts (analytics, affiliate widgets), update the script-src directive accordingly

6. Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=()

• Disables camera, microphone, and geolocation access
• Can be expanded or relaxed as needed

Verification

After applying the Transform Rule, verify headers are being sent:

Browser DevTools

1. Visit https://comfytechcheck.com
2. Open DevTools → Network tab
3. Click the first request (the HTML document)
4. Check the Response Headers section

Command Line (curl)

curl -sI https://comfytechcheck.com | grep -i -E "(strict-transport-security|x-content-type-options|x-frame-options|referrer-policy|content-security-policy|permissions-policy)"

Online Tools

• https://securityheaders.com – Scan the domain for a full report
• https://hstspreload.org – Check HSTS preload eligibility

Cache Busting & Static Asset Optimization

Method A: Enable Auto-Minify in Cloudflare Dashboard

Cloudflare can automatically minify CSS, JavaScript, and HTML at the edge, reducing file sizes without changing your source files.

1. Log into https://dash.cloudflare.com
2. Select the domain comfytechcheck.com
3. Navigate to Speed → Optimization
4. Scroll to the Auto Minify section
5. Enable the checkboxes for:
   • ☑ JavaScript
   • ☑ CSS
   • ☑ HTML
6. Click Apply

Note: Auto-minify works on cached assets. If you update a file, you may need to Purge Cache (Speed → Cache Purge) before visitors see the minified version of the updated file.

Method B: Version Query Strings for Long-Term Caching

For static assets (CSS, JS, images, fonts) that change infrequently, append a version query string to the URL. This lets Cloudflare and browsers cache the file aggressively (e.g., max-age: 31536000), but still fetch the new version when it changes.

Example:

<!-- Before (no versioning -- cache-busting relies on unpredictable filename) -->
<link rel="stylesheet" href="/assets/css/main.css">
<script src="/assets/js/app.js"></script>

<!-- After (version query string -- update the version number on each deploy) -->
<link rel="stylesheet" href="/assets/css/main.css?v=1.0.1">
<script src="/assets/js/app.js?v=1.0.1">

How it works:

• The ?v=1.0.1 query parameter is treated by Cloudflare and browsers as a different URL from ?v=1.0.0.
• Set a long Edge Cache TTL (e.g., 2+ years) under Speed → Cache → Edge Cache TTL so repeat visitors never re-download unchanged assets.
• When you deploy a new version, bump the version string on every changed asset. The browser sees a new URL and fetches the fresh file.

Recommendations for this site:

1. Enable Auto Minify (Method A above) for on-the-fly compression.
2. Use version query strings (v=1.0.1) on all <link> and <script> tags in _layouts/default.html or wherever static assets are referenced.
3. Additionally, consider setting a Cache Everything page rule for /assets/* with Edge Cache TTL of 1 month or longer (Speed → Cache → Cache Rules in the Cloudflare dashboard).
4. If you use Jekyll’s asset_url filter or a build-time hash plugin, those are alternatives – but a simple version string is the easiest starting point.

Important: The query string must change whenever the file content changes. If you forget to bump the version, visitors may continue to receive a stale cached copy. Use a deployment script or CI step that automatically increments the version number.

HTML Page Caching – Edge Cache TTL via Cloudflare Page Rule

GitHub Pages does not allow configuring Cache-Control headers on HTML responses. By default, GitHub Pages sends Cache-Control: no-cache for HTML pages, which means browsers and CDNs will revalidate every time, increasing latency and origin load.

To solve this, create a Cloudflare Page Rule that forces a 2-hour Edge Cache TTL for HTML pages.

Step 1 – Log into Cloudflare Dashboard

1. Go to https://dash.cloudflare.com
2. Select the domain comfytechcheck.com

Step 2 – Create the Page Rule

1. Navigate to Rules → Page Rules
2. Click Create Page Rule

Step 3 – Define the URL Pattern and Settings

• URL pattern: comfytechcheck.com/*
• Pick settings:
  • Cache Level: ➔ Cache Everything
  • Edge Cache TTL: ➔ 2 hours

  (Optionally add Browser Cache TTL: 2 hours to match.)

Step 4 – Save and Deploy

1. Click Save and Deploy
2. The rule becomes active within seconds

How it works

What this rule caches

Because the pattern is comfytechcheck.com/*, all responses (HTML pages, CSS, JS, images) will be cached at the edge for 2 hours. This is fine – Cloudflare automatically respects any Cache-Control headers that GitHub Pages does set on non-HTML assets (e.g., JS/CSS with far-future expires). The only practical change is that HTML pages, which previously were not cached, now get a 2-hour edge TTL.

Verification

# Check the cf-cache-status header -- should return "HIT" on repeat visits
curl -sI https://comfytechcheck.com/ | grep -i "cf-cache-status"

# Check the cache-control header Cloudflare returns to browsers
curl -sI https://comfytechcheck.com/ | grep -i "cache-control"

Alternative: Cloudflare Cache Rules (Newer Approach)

Cloudflare now recommends Cache Rules (under Rules → Cache Rules) over Page Rules for caching. They support more granular matching (e.g., by content type). To target only HTML pages:

1. Navigate to Rules → Cache Rules
2. Click Create cache rule
3. Rule name: HTML Cache -- 2h TTL
4. When incoming requests match:
   • Hostname equals comfytechcheck.com
   • Content Type equals text/html
5. Then:
   • Edge TTL: Override → 2 hours
6. Click Save

This is more precise – it only affects HTML responses and leaves asset caching untouched.

Notes

• GitHub Pages + Cloudflare proxy is a common setup. The _headers file in this repo is included for reference and would apply automatically if the site were migrated to Cloudflare Pages.
• HSTS preload: After confirming HSTS works, submit the domain to https://hstspreload.org for hardcoded HSTS in browsers.
• CSP tuning: If affiliate scripts or analytics are added, test the CSP in report-only mode first (Content-Security-Policy-Report-Only) to avoid breaking functionality.
• CORS (Access-Control-Allow-Origin): The site currently returns Access-Control-Allow-Origin: * on most responses (Cloudflare’s default for proxied origins). This is fine for a public blog – it allows any website to fetch your content via JavaScript (e.g., for embedded widgets or API access). If tighter CORS is ever needed (e.g., restricting to a specific origin like https://app.example.com), create a Cloudflare Transform Rule under Rules → Transform Rules → Modify Response Headers to override Access-Control-Allow-Origin with the desired value. The default (*) is acceptable and recommended for the current use case.
• Google Fonts & WOFF2 conversion: The site loads Inter and JetBrains Mono from Google Fonts (fonts.googleapis.com). Google Fonts automatically detects the visitor’s browser and serves WOFF2 (a highly compressed web font format) to all modern browsers. The raw TTF/OTF download size for these font families totals roughly 1.85MB, but this number is misleading – the actual transferred size is WOFF2, typically around 200–300KB combined for the weights used. Google’s CDN also handles character subsetting per page, so only the glyphs actually needed are downloaded. Do not attempt to self-host or pre-convert these fonts to WOFF2; Google’s server-side format negotiation is more performant and cache-friendly than any local workaround.