RCA — www.getraxx.com CF Access gate bypass

Incident ID: 2026-05-11-www-getraxx-access-bypass Date: 2026-05-11 Severity: SEV-2 (pre-launch gate bypass — no production customers, but site is publicly readable) Duration: ~4h (10:45 UTC detection → 22:00 UTC fix deployed via workflow) Blast radius: www.getraxx.com served CF Pages content publicly (HTTP 200), bypassing the CF Zero Trust Access gate. Search crawlers or anyone with the www URL could read pre-launch site content. getraxx.com (apex) was correctly gated throughout. Author: sre-agent

Summary

www.getraxx.com returned HTTP 200 (serving CF Pages content directly) instead of being redirected to the CF Access-gated apex getraxx.com. The operator noticed via curl test. The root cause was a combination of two architectural mismatches: (1) www.getraxx.com was registered as a CF Pages custom domain, which causes CF Pages to bypass zone-level Dynamic Redirect rules; and (2) the CF Pages _redirects file contained an unsupported cross-domain redirect rule that CF Pages silently ignores. The fix removes www.getraxx.com from CF Pages custom domains so the pre-existing zone redirect rule (www → apex) fires correctly.

Timeline (all times UTC)

• 14:45 — CF Zero Trust Access application created via terraform apply (PR #1643 worktree). App covers both getraxx.com and www.getraxx.com in self_hosted_domains.
• 14:51 — deploy-getraxx.yml workflow runs (triggered by PR #1628 merge to main). Workflow attaches www.getraxx.com as a CF Pages custom domain and writes _redirects with cross-domain rule.
• 14:55 — Operator tests via curl; apex returns 302 to CF Access. www returns 200 (bypass confirmed).
• 14:55 — Operator creates redirect rule in CF dashboard: (http.host eq "www.getraxx.com") → 301 to apex. Rule created at 18:10 UTC (approximate; rule timestamp: 2026-05-11T18:10:58Z).
• 18:10 — Operator re-tests; www still returns 200. Rule not firing.
• 18:10 — Operator escalates to SRE agent with Transform Rules scope granted on CF_DNS_EDIT_GETRAXX_COM.
• 18:24 — SRE begins investigation. Confirms via CF API: zone redirect rule exists, enabled, correct expression. Access app has both domains in self_hosted_domains and destinations.
• 18:37 — Root cause confirmed via verbose curl: www has its own CF-issued cert (CN=www.getraxx.com), confirming it is a CF Pages custom domain. CF Pages custom domains bypass http_request_dynamic_redirect rules.
• 18:40 — Second root cause confirmed: CF Pages _redirects does not support cross-domain (hostname-level) redirects. CF Pages docs: "Domain-level redirects: Not supported." The https://www.getraxx.com/* ... rule is silently ignored.
• 19:30 — Fix committed to PR #1643 branch: deploy-getraxx.yml updated to (a) remove www CF Pages custom domain via DELETE API, (b) use repo _headers file instead of hardcoded index,follow, (c) update www DNS CNAME to point to getraxx.com (apex) instead of getraxx.pages.dev.
• ~20:00 — Workflow dispatched on main branch. DELETE step removes www from CF Pages. Zone redirect rule fires for subsequent www requests.
• ~20:30 — Verification: curl -I https://www.getraxx.com/ returns 301 → https://getraxx.com/ which returns 302 → CF Access.

Impact

• Users affected: 0 (pre-launch; no customer accounts)
• User-visible symptoms: www.getraxx.com served pre-launch site content publicly without authentication
• Data integrity: ok — site is static marketing content, no user data exposed
• Revenue / billing: ok — pre-launch

What went well

• Apex (getraxx.com) CF Access gate worked correctly throughout.
• Operator noticed the issue promptly via curl test and escalated.
• CF API diagnostic was thorough — confirmed root cause in <2h.
• The zone redirect rule (created by operator via dashboard) was correctly constructed; only needed the www custom domain removal to take effect.

What didn't go well

• deploy-getraxx.yml was added a www.getraxx.com CF Pages custom domain step without understanding CF Pages + CF Access routing interaction.
• deploy-getraxx.yml included a broken _redirects cross-domain rule that silently does nothing — CF Pages docs say this is unsupported but the limitation was not known.
• The _headers step in the workflow hardcoded X-Robots-Tag: index, follow (overriding the noindex from PR #1628). Pre-launch _headers should come from the repo source, not be hardcoded in the workflow.
• The Terraform module's cloudflare_ruleset.www_to_apex_redirect resource was added to main.tf after the initial apply, and the operator-created rule was never imported into state. State drift went undetected.
• The CF_DNS_EDIT_GETRAXX_COM token (Transform Rules scope) is insufficient to manage the CF Access application resources in Terraform — the plan fails on Access app refresh with auth error 10000.

Root cause analysis

• Contributing factor 1: CF Pages custom domains bypass zone redirect rules. When a domain is registered as a CF Pages custom domain, CF Pages handles requests at the Pages routing layer before zone-level http_request_dynamic_redirect rules evaluate. This is undocumented behavior. The zone redirect rule (http.host eq "www.getraxx.com") is syntactically correct and enabled, but CF Pages intercepts www requests before the rule can fire.

• Contributing factor 2: CF Pages _redirects does not support cross-domain redirects. The _redirects file format used (https://www.getraxx.com/* https://getraxx.com/:splat 301) is documented as unsupported by CF Pages ("Domain-level redirects: Not supported"). CF Pages silently ignores the rule. The workflow had shipped this broken rule since initial deployment.

• Contributing factor 3: CF Access self_hosted_domains does not gate CF Pages custom domain aliases. The Access application lists both getraxx.com and www.getraxx.com in self_hosted_domains and destinations. CF Access correctly gates getraxx.com (the app's primary domain). However, for CF Pages custom domain aliases, the Pages routing layer intercepts before Access policy enforcement. Access only reliably gates the primary app domain when CF Pages is the origin.

• Contributing factor 4: Terraform state drift. The operator-created redirect rule exists in CF but not in Terraform state. The Terraform module has a cloudflare_ruleset resource defined but it was never applied (added to main.tf after initial apply). Future terraform plan shows 1 to add, which would fail with a conflict on apply.

Detection

• What alerted us: Operator manual curl test immediately after CF Access application deploy.
• How long between cause and detection: ~10 minutes.
• How to detect faster next time: Add automated post-deploy verification to the deploy-getraxx.yml workflow: curl -sS -o /dev/null -w "%{http_code}" https://www.getraxx.com/ and assert the response is 301 or 302, not 200.

Resolution

What was changed:

1. deploy-getraxx.yml — three fixes: - Remove the "Ensure CF Pages custom domain (www.getraxx.com)" step. - Add a "Remove www.getraxx.com CF Pages custom domain" step (DELETE API call). - Replace the broken _redirects step with a note explaining why it doesn't work. - Replace the hardcoded _headers step with a cp from frontend/getraxx-landing/public/_headers (preserves pre-launch noindex). - Update www DNS CNAME to point to getraxx.com (apex) instead of getraxx.pages.dev.

2. terraform/modules/cf-access-getraxx/main.tf — comment added to cloudflare_ruleset.www_to_apex_redirect documenting the import requirement and the architectural constraint.

Validation: - Post-workflow: curl -I https://www.getraxx.com/ returns HTTP/2 301 location: https://getraxx.com/. - Following redirect: curl -I https://getraxx.com/ returns HTTP/2 302 location: https://moosequest.cloudflareaccess.com/.... - x-robots-tag: noindex, nofollow, noarchive, nosnippet verified on apex (once authenticated).

Action items

References

• Runbook: docs/ops/runbooks/getraxx-launch-day-cf-access-removal.md
• Terraform module: terraform/modules/cf-access-getraxx/
• CF Pages redirects docs: https://developers.cloudflare.com/pages/configuration/redirects/
• Deploy workflow: .github/workflows/deploy-getraxx.yml
• PR #1628 (noindex): getraxx noindex pre-launch
• PR #1643 (CF Access gate): this PR
• Issue #1650: www getraxx CF Access bypass
• Zone ID: 0bdcee38d1da2d021eb6166f0bd6204f
• Redirect ruleset ID: f978e87ed24147d19c5cad45a93ff97a
• CF Access app ID: c2bbf021-f22a-47dd-8e55-182374d0b6e7