· Iren Saltali · security · 2 min read
Public Routes, Private Routes, and Least Privilege
How to shape an API contract so public endpoints stay useful without turning the gateway into a loose front door.
The short answer: Least privilege at the gateway means deciding route by route what should be reachable publicly, what should require identity, and what should never be client-facing at all.
When to read this
- You are designing a new route tree.
- You are cleaning up an API where auth rules accumulated ad hoc.
- You want fewer accidental exposures in public traffic.
What matters in practice
- Public should be intentional, not the default fallback.
- Separate operational routes from end-user routes.
- Route docs should explain who the audience is for each endpoint family.
Concrete example
{
"authorizer": {
"type": "jwt",
"secret": "$secret.JWT_SECRET",
"algorithm": "HS256",
"issuer": "https://issuer.example.com",
"audience": "api-audience"
},
"paths": [
{ "method": "GET", "path": "/health", "response": { "status": "ok" } },
{
"method": "GET",
"path": "/private/orders",
"auth": true,
"integration": { "type": "http_proxy", "server": "orders" }
}
]
}The example above is intentionally small because the best gateway configs stay readable. Add only the route, auth, and mapping behavior you actually need.
How this maps to the current gateway
The current codebase already supports the behavior discussed here through its config schema, route matcher, and integration handlers. That is why this project is a good fit for reader-first examples: the docs and blog can point to real, implemented behavior instead of hypothetical gateway features.
What this product does not do
- This project does not implement attribute-based authorization policies out of the box.
- Least privilege still requires business-level access checks in downstream systems.
FAQ
Can a route be public today and private later?
Yes, but document the change and coordinate consumers because auth behavior is part of the contract.
Should all health routes be public?
Usually yes, but keep them minimal and non-sensitive.
Related docs
- auth route design public vs private
- protect one route not your whole api
- security limitations and non goals
Last reviewed: March 6, 2026
