Securing Your APIs

Authentication answers 'who are you?' Authorisation answers 'what are you allowed to do?' Both must be correct. Confusing them is the most common API security mistake. For Supabase-backed APIs: Supabase handles authentication (JWTs issued on login, verified on every request). Row Level Security (RLS) handles authorisation (users can only see their own data, enforced at the database level). Using both correctly means: even if your application layer has a bug that sends a request with the wrong user ID, the database will refuse to return the data. JWT best practices: set short expiry times (15 minutes for access tokens, 7 days for refresh tokens). Validate the signature on every request — never trust a JWT's payload without verifying the signature against your signing key. Store access tokens in memory (not localStorage — XSS vulnerable) and refresh tokens in httpOnly cookies (not accessible to JavaScript). Supabase's client SDK handles this correctly by default — don't override its storage mechanism.

Rate limiting protects your API from abuse — whether accidental (a client with a bug making thousands of requests) or deliberate (a credential stuffing attack trying thousands of password combinations). Implement rate limiting at multiple levels: per IP, per user, per endpoint. For Cloudflare Workers: Cloudflare's rate limiting is built in and costs $0.05 per million requests above the free tier. Configure rules like '100 requests per minute per IP on /auth/login' — this directly blocks credential stuffing without any application code. For Supabase: the built-in auth rate limiting protects the authentication endpoints. For your own API routes, implement rate limiting in middleware using an in-memory store (for single-instance) or Redis/Cloudflare KV (for distributed deployments). Input validation: validate all input at the API boundary, not just in the client. Every field should have: type validation, length validation, format validation (email, UUID, etc.), and sanitisation for stored values. Use a schema validation library (Zod for TypeScript, Joi for JavaScript) on every API handler. A single missing validation on an assessment ID field could allow a user to enumerate other users' assessments — a classic IDOR (Insecure Direct Object Reference) vulnerability.