Pre-auth anti-abuse gate

Many of the most valuable APIs on a public site can't sit behind a login — address lookups, product search, quote calculators, AI chat widgets. They're how the user gets to the login. But "no login required" isn't the same as "safe to leave wide open" — most of them cost real money on every call.

Why an open API is a security problem, not just an availability one

• Address lookup at checkout. Loqate, getAddress.io and Postcoder charge per autocomplete request — typically £0.001–£0.005. A scraper hammering /api/address/lookup?postcode=… burns your vendor bill, not theirs, and the invoice arrives next month.
• Pre-login pricing and quote pages. Comparison sites and aggregators (insurance, energy, FX, travel) call paid upstream providers before the user is identified. Every render is a paid lookup; a bot pulling 100k quote variants per hour can clear a five-figure vendor bill in a day.
• "Talk to our docs" widgets. An LLM-backed search or chat answer on a landing page issues an inference call per query — at roughly $0.01–$0.05 each, a few thousand bot requests is a real number. And LLMs are the new favourite scraping target.
• Maps, geocoding, place autocomplete. Google Places, Mapbox, Algolia all bill per query. Google Places autocomplete is ~$2.83 per 1,000 requests with no in-built caching.
• Your own cloud bill. Even endpoints that hit "free" internal data burn CPU, egress, and database read-units. Cloud Run will happily scale to absorb 100k req/s for you; your monthly invoice may not.
• Inventory and pricing leakage. Competitors scraping your pre-login product feed, stock levels, or live prices is the original use case for the gate — they pay nothing, you pay both the infra cost and the strategic cost of having your catalogue mirrored.

You can't put these endpoints behind a session — they precede the session. But you can put a gate between "any HTTP client on the planet" and "a browser that came from your own site and proved it with one round-trip." That gate is what this demo is.

How the gate works

This page calls a tiny Go backend that mints an HMAC-bound token and an HttpOnly cookie. The frontend then makes lookups carrying both. The cookie auto-attaches; the token must be explicitly sent as X-CSRF-Token. Every part has a deliberate rate limit.

Pattern adapted from OWASP's Signed Double-Submit Cookie CSRF defence (cookie nonce + signed header token, validated with HMAC). Repurposed here pre-authentication as a cost-protection gate for open APIs, addressing OWASP API4:2023 — Unrestricted Resource Consumption.

Backend config (returned by /api/v1/mint)

Current token

(minting on load…)

Format: nonce | expiry_unix | hmac_sha256(server_secret, "nonce|expiry"). The nonce half is also sitting in your cookie jar as __session — HttpOnly, so this JS can't read it; only the server can compare it with the header. (Named __session because Firebase Hosting strips every cookie except that one before reaching Cloud Run.)

Call the protected endpoint

Try to bypass

Open a terminal and try these.

No cookie, no token — fails at the validate step:

curl -i http://localhost:5050/api/v1/lookup

Forged token, no cookie:

curl -i -H "X-CSRF-Token: abc|9999999999|fakehash" http://localhost:5050/api/v1/lookup

The legitimate two-step (works, but costs an entry-API round-trip per token-burst):

BASE=http://localhost:5050
TOKEN=$(curl -s -c /tmp/jar "$BASE/api/v1/mint" | sed -nE 's/.*"token":"([^"]+)".*/\1/p')
curl -i -b /tmp/jar -H "X-CSRF-Token: $TOKEN" "$BASE/api/v1/lookup"

Burst the mint endpoint — drains the token bucket and 429s:

for i in $(seq 1 25); do
  curl -s -o /dev/null -w "mint %{http_code}\n" http://localhost:5050/api/v1/mint
done

Demo vs production reality

The demo strips several production realities that meaningfully change the economics of scraping. In a real deployment the bot's job is much harder than what you see here: