Skip to content

Security

Jump to bottom
Jagrit edited this page Jul 17, 2026 · 2 revisions

Security Features

Security is the primary reason the Zuup Auth Gateway exists. This page outlines the specific security mechanisms implemented at the edge to protect our infrastructure.

Zero Leakage (Secret Substitution)

When the Edge Proxy receives a request from a client application (e.g., https://auth.zuup.dev/rest/v1/...), it intercepts the HTTP headers and reads the 100-character Gateway Secret.

If the secret matches our allowed keys, the proxy:

  1. Drops the Gateway Secret from the headers.
  2. Injects the true SUPABASE_ANON_KEY or SUPABASE_SERVICE_ROLE_KEY depending on the route and user validation.
  3. Redirects the fetch request to the real database URL.

If an attacker attempts to scrape the Gateway Secret and run arbitrary queries, the Edge Proxy will aggressively block them because it enforces strict Origin validation and rate limiting before forwarding any traffic.

Bot Protection (Cloudflare Turnstile)

Authentication routes are historically the most abused endpoints on any application. To prevent credential stuffing and brute-force attacks, we enforce Cloudflare Turnstile on all our login, signup, and password reset routes.

The Edge Proxy intercepts the cf-turnstile-response token submitted by the frontend form and performs a server-side verification against Cloudflare's API before it even touches our database to check user credentials.

Edge Rate Limiting

We leverage Cloudflare KV to maintain distributed, low-latency rate limit counters based on client IPs and User-Agents.

If an endpoint is hammered, the edge immediately returns a 429 Too Many Requests without the core database ever knowing an attack occurred. This prevents our Supabase instance from being overwhelmed by DDoS attacks.

Admin Roles & Deep Authorization

We enforce strict deep authorization on privileged endpoints. For example, endpoints that require the SUPABASE_SERVICE_ROLE_KEY (such as /api/admin/users) are heavily protected.

The Proxy extracts the JWT from the incoming request, verifies it with the database, and asserts that the user.email matches the ADMIN_EMAIL configured in the edge environment variables. If it does not match, a 403 Forbidden is returned immediately.

Clone this wiki locally