6 · Cloudflare CDN

TL;DR

Objective — front the app with Cloudflare on the Free plan (TLS termination, DDoS absorption, a WAF, global caching): nameserver cutover, API-driven DNS, Full (Strict) SSL + HSTS, WAF and rate limiting, cache rules, DNSSEC, and a final API verification probe — with Rocket Loader OFF for Laravel.

Steps at a glance:

1. Budget against the Free plan — Free tier limits are real — plan inside them so nothing silently fails to apply.
2. Add the zone and cut over nameservers — add the zone and switch nameservers, so Cloudflare can proxy traffic before security and cache rules are configured.
3. Configure DNS via the API — Drive record changes through the API so they’re scriptable and auditable. Use a scoped token (Zone:DNS:Edit), never the global key.
4. Set SSL/TLS and HSTS — set Full Strict TLS and HTTPS enforcement, so browser-to-edge and edge-to-origin traffic are both protected.
5. Configure security: WAF + rate limiting — Spend the 5 WAF rules on real threats (block bad bots, restrict /admin by country/ASN, challenge suspicious paths).
6. Configure caching and speed — cache only safe static assets and enable speed features, so performance improves without breaking authenticated Laravel routes.
7. Enable DNSSEC and Zero Trust — turn on DNSSEC and Zero Trust where appropriate, so DNS tampering risk drops and protected admin paths have an extra access layer.
8. Run the final verification probe — Confirm the edge is live, encrypted end-to-end, and DNSSEC-validated.

User part + done-when

🔀 User part — the human owns Cloudflare/registrar login, 2FA, plan choices, nameserver cutover authorization, DS publication approval, and any production-impacting toggle. With an authorized browser session or scoped token, the agent can drive non-secret Cloudflare setup, apply/audit API-supported records and rules, verify UI state, and run the final probes. Treat provider-console work with the vendor console automation guide.

Done when the zone is Active on Cloudflare nameservers, SSL is Full (Strict) with HSTS, WAF + one rate-limit rule are within budget, the static-asset cache rule is live, Rocket Loader is off, DNSSEC is active, and the probe shows cf-ray, the HSTS header, and "status":"active".  ·  ⏱ ~45–60 min (+ nameserver propagation)  ·  🔀 mixed (👤 dashboards, 🤖 API DNS + probe).

Background

SHOULD — edge security + performance

Cloudflare adds a caching/security edge in front of the origin: TLS termination, DDoS absorption, a WAF, and global caching. This page configures it on the Free plan, which covers everything a typical CodeCanyon launch needs.

Actor labels for Cloudflare work

• API-automatable — DNS record upserts, many ruleset reads/writes, and verification probes when the token has the right scope.
• Browser/user-gated — account creation, nameserver registrar changes, some plan/UI toggles, and any action that needs credentials or a paid decision.
• Token-scope-dependent — if the API returns 403 / 9109, treat it as a scope gap until feedback_api_scope_verification.md says otherwise. Record the Cloudflare account, zone, token name, and allowed scopes in Zaj-PROJECT.md so multi-account work does not hit the wrong tenant.

Steps

1. Budget against the Free plan

Free tier limits are real — plan inside them so nothing silently fails to apply.

Resource	Free-plan budget	Notes
WAF custom rules	5	Spend on the highest-value blocks
Rate-limiting rules	1	Reserve for login/API abuse
Cache rules	a few	One good static-asset rule goes far
Page Rules (legacy)	3	Prefer modern Rules where possible

Free-plan rate-limit rule requires two extra API fields

On the Free plan you get one rate-limit rule, and the API rejects the rule unless the ratelimit object includes both mitigation_timeout and characteristics.

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/<zone-id>/rulesets/phases/http_ratelimit/entrypoint" \
  -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json" \
  --data '{"rules":[{
    "expression": "(starts_with(http.request.uri.path, \"/admin\")) or (starts_with(http.request.uri.path, \"/login\"))",
    "action": "block",
    "ratelimit": {
      "requests_per_period": 10, "period": 10,
      "mitigation_timeout": 10,
      "characteristics": ["cf.colo.id", "ip.src"]
    },
    "description": "Rate limit admin + login (10 req/10s)"
  }]}'

Scope the single rule to /admin + /login only — never the landing page or public API. Additional rate-limit rules require Pro.

2. Add the zone and cut over nameservers

Who does this

🔀 User + Agent — 👤 the user authorizes Cloudflare/registrar access and any live nameserver cutover. 🤖 With an authorized browser/API token, the agent can drive non-secret setup, audit imported records, and verify the zone with dig. Use vendor console automation when a provider console is the safest path.

1. Add the site as a zone in Cloudflare; it imports existing records — audit the import against what page 2 and page 5 created.

   • ✅ The zone exists and its imported records have been audited.

2. Update the registrar’s nameservers to Cloudflare’s pair, then wait for the zone to go Active.

   dig NS example.com    # returns Cloudflare nameservers once Active
   # Expected: the NS query returns Cloudflare's nameserver pair

   • ✅ dig NS example.com returns Cloudflare and the zone shows Active.

Re-check email DNS after import

Confirm the SPF/DKIM/DMARC/MX records from 5 · DNS email survived the import intact — a dropped MX silently kills mail.

3. Configure DNS via the API

Drive record changes through the API so they’re scriptable and auditable. Use a scoped token (Zone:DNS:Edit), never the global key. Before mutating, read the current record and save its ID/content/proxied value so rollback is one PATCH away.

Do not orange-cloud production before origin TLS

For a fresh production domain, proxied:true sends public traffic through Cloudflare immediately. If the origin site does not exist yet, DNS still points at an old box, or the origin certificate is missing, visitors get Cloudflare 525 SSL handshake failed.

Before setting the production record to orange-cloud:

PROD_DOMAIN="<production-domain-from-Zaj-PROJECT>"
EXPECTED_ORIGIN_IP="<production-origin-ip-from-Zaj-PROJECT>"
dig +short "$PROD_DOMAIN" A | grep -Fx "$EXPECTED_ORIGIN_IP"
# Expected: DNS reaches the current origin box, not a stale server

If Hostinger/Let’s Encrypt cannot validate through the proxy, keep the record DNS-only (proxied:false, grey cloud) until the origin cert is issued. Then switch to proxied:true and set SSL mode to Full (Strict).

1. Upsert records through the API — load the token from vault or a mode-600 file; never export CF_API_TOKEN="<literal>" in a runbook (visible in shell history and ps):

   # CF_API_TOKEN and ZONE_ID already exported from vault / ~/.zshrc (see Phase 1 machine setup)
   RECORD_NAME="app.example.com"
   ORIGIN_IP="<origin-ip-from-Zaj-PROJECT>"
   EXISTING_ID="$(curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?type=A&name=$RECORD_NAME" \
     -H "Authorization: Bearer $CF_API_TOKEN" | jq -r '.result[0].id // empty')"
   
   if [ -n "$EXISTING_ID" ]; then
     METHOD="PATCH"; URL="https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$EXISTING_ID"
   else
     METHOD="POST"; URL="https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records"
   fi
   
   curl -s -X "$METHOD" "$URL" \
     -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json" \
     --data "{\"type\":\"A\",\"name\":\"$RECORD_NAME\",\"content\":\"$ORIGIN_IP\",\"proxied\":true}"
   # Expected: a JSON response with "success":true and the created/updated record

   • ✅ Records are created/updated via the scoped-token API; proxied:true (orange cloud) is used for production only after the stale-DNS check passes and origin TLS exists. false (grey cloud) is DNS-only and is the safe temporary state for certificate issuance.

Idempotency and rollback

Never create duplicate A/CNAME records for the same host. Read first, patch when present, and keep the previous content/proxied value in the work log before changing it. Rollback is a PATCH back to the previous IP/proxy state, not a second record.

4. Set SSL/TLS and HSTS

Who does this

🔀 Authorized agent + user gate — 🤖 the agent may set SSL mode, Always Use HTTPS, and HSTS through the Cloudflare API or an authorized browser session after token/account scope is proven. 👤 The user authorizes any live DNS/proxy/HSTS change and supplies dashboard login or token access; the agent does not guess or bypass Cloudflare permissions.

• Set SSL mode to Full (Strict) — encrypts edge↔origin and validates the origin cert. Flexible causes redirect loops and is insecure.
• Enable Always Use HTTPS.
• Enable HSTS only once you’re confident HTTPS is permanent (it’s hard to undo): max-age ≥ 6 months, include subdomains, preload optional.

525 is a bring-up signal, not an app error

Cloudflare 525 means the edge could not complete TLS with the origin. Check DNS first (dig +short must match the current origin IP), then the origin certificate. Do not debug Laravel, rotate APP_KEY, or rerun the installer for a 525.

5. Configure security: WAF + rate limiting

Spend the 5 WAF rules on real threats (block bad bots, restrict /admin by country/ASN, challenge suspicious paths). Use the single rate-limit rule on the login or API endpoint most likely to be brute-forced.

Load feedback_api_scope_verification.md before labeling a Cloudflare security action as dashboard-only. Many Cloudflare failures are token-scope issues, not missing API support; probe first and record whether the action is API-automatable, token-scope-dependent, or truly browser-gated.

6. Configure caching and speed

• Cache rule: cache static assets (/build/*, /images/*) aggressively; bypass cache for authenticated/app routes and anything with a session cookie.
• Enable Brotli and Tiered Cache. (Cloudflare removed Auto Minify in Aug 2024 — minify in your build pipeline instead.)

Rocket Loader must stay OFF for Laravel

Rocket Loader defers and reorders JavaScript, which breaks Laravel apps that rely on inline script ordering, CSRF token injection, and Livewire/Alpine/Vite-bundled scripts. Leave Rocket Loader = off. Enabling it is a frequent “the app’s JS randomly breaks in production” cause.

7. Enable DNSSEC and Zero Trust

• Enable DNSSEC in Cloudflare, then add the DS record it generates at your registrar — DNSSEC isn’t active until the registrar side is done.
• Optionally protect staging with Zero Trust Access (email-OTP gate) so the unfinished site isn’t public.

1. Publish the DS record in order.

   DOMAIN="example.com"
   # 1) Cloudflare dashboard/API: enable DNSSEC and copy Key Tag, Algorithm, Digest Type, Digest.
   # 2) Registrar: publish exactly those DS values.
   dig +short DS "$DOMAIN" @1.1.1.1
   # Expected: one DS row after registrar publication; before publication this can be empty

   • ✅ Cloudflare DNSSEC is enabled and the registrar publishes the matching DS row.

Namecheap DS recipe

Namecheap path: Domain List → Manage → Advanced DNS → DNSSEC → Add DS record. Copy Cloudflare’s Key Tag, Algorithm (commonly 13), Digest Type, and Digest exactly. Save, wait for propagation, then verify with dig +short DS <domain> @1.1.1.1.

8. Run the final verification probe

Confirm the edge is live, encrypted end-to-end, and DNSSEC-validated.

1. Probe the zone over HTTP and the API.

   # Zone is active and proxied (expect cf-ray + cf-cache-status headers)
   curl -sI https://app.example.com | grep -iE 'cf-ray|cf-cache-status|strict-transport'
   
   # SSL mode end-to-end (expect HTTP/2 200, valid cert)
   curl -sI https://app.example.com | head -1
   
   # DNSSEC DS published at the registrar
   dig +short DS example.com @1.1.1.1
   
   # DNSSEC validated via a validating resolver (AD bit)
   dig +dnssec @1.1.1.1 example.com A | grep -q 'flags:.* ad' && echo "DNSSEC validated"
   dig DNSKEY example.com +short | grep -q . && echo "DNSKEY published"
   
   # Zone status via API
   curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID" \
     -H "Authorization: Bearer $CF_API_TOKEN" | grep -o '"status":"[^"]*"'
   # Expected: cf-ray present (proxied), a strict-transport-security header, DS row present,
   #           zone "status":"active", and DNSSEC validated

   • ✅ The probe shows cf-ray (proxied), the strict-transport-security header (HSTS), zone "status":"active", and DNSSEC validated.

Cloudflare API read-value gotchas in the probe

Three API behaviors trip up verification probes — none are failures by themselves:

• tls_1_3 can read back as "zrt", not "on". That means TLS 1.3 with 0-RTT. Only "off" or ERR are failures.
• List rules by phase via the entrypoint endpoint, not a query param: GET /zones/<zone>/rulesets/phases/<phase>/entrypoint. The intuitive /rulesets?phase=<phase> can silently return the full ruleset list.
• browser_check may read back empty on some API versions even when enabled — fall back to the dashboard instead of treating blank as off.

curl -s "https://api.cloudflare.com/client/v4/zones/<zone-id>/rulesets/phases/http_ratelimit/entrypoint" \
  -H "Authorization: Bearer $CF_API_TOKEN"
# Expected: the rules array for that phase only; a missing entrypoint means zero rules for the phase

Checklist

Do not mark this step done until every box below is checked.

• 👤 Zone Active — nameservers are Cloudflare’s; imported records audited (esp. email DNS).
• 🔀 Production origin safe — production A record resolves to the current origin and origin TLS is valid before orange-cloud proxying.
• 👤 SSL hardened — SSL = Full (Strict), Always Use HTTPS on, HSTS set.
• 👤 WAF within budget — WAF rules + 1 rate-limit rule within Free-plan budget.
• 🔀 Cache rule live — static-asset cache rule live; app/auth routes bypass cache.
• 🔀 Rocket Loader OFF; DNSSEC active — DS added at registrar and dig +short DS <domain> @1.1.1.1 returns the Cloudflare values.
• 🤖 Probe green — verification probe shows cf-ray, HSTS header, and "status":"active".

→Next step

Release + incident response