api-hardening

API hardening

Most breached endpoints were authenticated. The pattern is not "no login" — it is "logged in, and the handler never checked that this row belongs to this caller." Authorization is per route, per object, every time. This skill is the server-side pass that goes route by route.

When to activate

• Any new or changed endpoint: REST route, GraphQL resolver, RPC/tRPC procedure, server action, webhook receiver, queue consumer, cron entry.
• Anything touching auth, sessions, roles, tenants, payments, uploads, or PII.
• A bug report shaped like "user A can see user B's data" or "it 500s with a weird message".
• Before a deploy that exposes a new surface publicly.

Route inventory first

Enumerate what exists before judging it. Grep the router, not your memory:

# Node/Next
rg -n "app\.(get|post|put|patch|delete)|router\.(get|post|put|patch|delete)" src
rg -n "export async function (GET|POST|PUT|PATCH|DELETE)" app
rg -n "'use server'" -l app src
# Python / Go / PHP
rg -n "@app\.(route|get|post)|@router\.(get|post)" .
rg -n "http.HandleFunc|mux.Handle" .
rg -n "Route::(get|post|put|delete)" routes

Build a table: method+path · auth required? · role/scope · object-ownership check · input validated? · rate limited? Every empty cell is a finding.

1. Authentication vs authorization

• Authentication answers who; authorization answers may they, on this object. Middleware usually gives you the first and never the second.
• Default deny. Public routes are an explicit allow-list, not "everything the middleware matcher forgot". Verify the matcher: a regex that misses /api/admin/../users or a trailing slash is a bypass.
• IDOR / BOLA — the top one. Any handler taking an id from the request must scope the query by the caller: where id = :id and owner_id = :caller (or tenant/org id). Filtering after the fetch, or trusting a userId sent in the body/JWT payload the client can re-sign, is not a check.
• Return 404 for objects the caller may not see, 403 only where existence is not sensitive. A 403 confirms the id exists.
• Role checks server-side only, from the session/token verified this request — never from a header, query param, or hidden form field.
• Multi-tenant: the tenant id comes from the session, never from the payload. In Postgres/Supabase, RLS is the second wall, not the only one — see supabase-setup.