Web surface posture — pre-launch lock-down

Author: 2026-04-28 surface-area review (Kristerpher + Claude) Status: living document — update when surfaces are added or postures change.

Principle

Pre-launch, default to least exposure. Operator surfaces (console, vault, internal docs) are CF Access gated. Customer-facing surfaces that are not yet ready for customers (Antlers app, customer docs, support portal) get a CF Access gate too — invite-only access via Cloudflare Zero Trust until GA. Marketing site (getraxx.com) and the company brand site (moosequest.net) stay public.

Heroku origin URLs (*.herokuapp.com) bypass Cloudflare entirely. The Cloudflare-origin guard middleware (#252 / PR #443 + console port) rejects any request that did not transit Cloudflare.

Surface matrix

Operator runbook — ordered actions

1. Enable origin guard on staging API (start the soak)

heroku config:set FLAG_ENFORCE_CF_ORIGIN=true --app raxx-api-staging
heroku ps:restart --app raxx-api-staging

Verify after restart:

# Direct origin → 403 (the change worked)
curl -i https://raxx-api-staging-1a19fb3873b9.herokuapp.com/api/system/status
# CF-proxied → still 200 (CF Access protects this so you'll see the access redirect; that's correct)
curl -i https://api-staging.raxx.app/api/system/status

Soak ≥24 h. Watch heroku logs --app raxx-api-staging --tail | grep direct_origin_blocked for false positives.

2. Enable origin guard on prod API (after staging soak passes)

heroku config:set FLAG_ENFORCE_CF_ORIGIN=true --app raxx-api-prod
heroku ps:restart --app raxx-api-prod

Same verify pattern.

3. Enable origin guard on prod console (after this PR ships)

heroku config:set FLAG_ENFORCE_CF_ORIGIN=true --app raxx-console-prod
heroku ps:restart --app raxx-console-prod

Verify: curl https://raxx-console-prod-ff30a22abccb.herokuapp.com/health still returns 200 (allowlisted), but curl https://raxx-console-prod-ff30a22abccb.herokuapp.com/secrets now returns 403.

4. CF Access gate raxx.app (pre-launch)

Cloudflare Zero Trust → Access → Applications → + Add an application → Self-hosted

• Application name: Raxx Antlers (pre-launch)
• Domain: raxx.app, plus *.raxx.app if you want to cover subdomains broadly
• Session duration: 24h
• Identity providers: pick whichever email you use (Google Workspace if your kris@moosequest.net is on it)
• Policy 1 — operator: include emails: kris@moosequest.net (+ any ops support emails)
• Policy 2 — Founders waitlist (optional): include email domains or specific allowlisted addresses pulled from your waitlist
• Save

When you go GA, either delete the application or change the policy to "Allow everyone" (effectively no gate).

5. Fix getraxx.com DNS

Cloudflare DNS panel → confirm:

• getraxx.com A or CNAME points at the CF Pages project (getraxx.pages.dev)
• Proxied (orange cloud)
• TLS edge cert provisioned

If the CF Pages project is missing, run wrangler pages project create getraxx then deploy via the existing pipeline.

6. Add www.raxx.app redirect

Cloudflare DNS panel:

• www CNAME → raxx.app (proxied)
• Page rule (or transform rule on the Free plan): www.raxx.app/* → 301 → https://raxx.app/$1

7. Future surfaces

• support.raxx.app — when #449 lands, gate /admin/* only.
• docs.raxx.app — when #423 ships, fully public + indexable.
• status.raxx.app — live as of #602 (holding page); React app (#604) replaces it. Stays public, no Access gate, indexable forever.

What's NOT in this doc

• WAF rules per surface (rate limits, bot fight mode) — that's a follow-up once these baseline gates are in place.
• mTLS or service-token-only access on bot endpoints — already in place at vault.raxx.app via CF Access service tokens; replicate to other internal-only surfaces if traffic patterns demand.
• Customer-side authentication mechanics inside Antlers (passkeys, etc.) — that's app-level, not surface-level.

Refs

• 252 / PR #443 — Cloudflare-origin guard for backend_v2

• This PR — same guard ported to console

• 217 — moosequest.net registrar lock

• 449 — FreeScout / support.raxx.app

• 423 — customer docs / docs.raxx.app

• 104 — public docs site foundation

• docs/architecture/break-glass-auth.md (#334) — how an operator regains access if CF Access locks them out