auth-boundaries
Skill1 starsChanged 44 days agoMITView on GitHub
Autenticación y autorización correctas: sesiones vs JWT, access/refresh tokens, OAuth2 + PKCE, OIDC, SSO, API keys, contraseñas y permisos deny-by-default con tests negativos. Úsala cuando la tarea toque login, logout, registro, sesiones, cookies, tokens, JWT, OAuth, "Sign in with…", SSO/SAML, API keys, roles, permisos, middleware de auth, RLS o "solo el dueño puede…", aunque el usuario no diga "auth". También al revisar IDOR o fugas entre usuarios o tenants.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- kleosr/bridleword for word, first seen Sep 29, 2026
Other versions1 project uses a version of this.
Word for word · 1
- kleosr/bridle★ 1100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- asd-ste100Skill
- bridle-harnessSkill
- code-architectureSkill
- cqrs-data-flowSkill
- debuggingSkill
- handoffSkill
- live-ui-syncSkill
- production-readinessSkill
- prompt-briefSkill
- slop-guardSkill
- system-designSkill
- testingSkill
The file
Files
Auth boundaries
Authn responde quién eres. Authz responde qué puedes tocar. Casi todas las fugas reales son authz faltante en un endpoint que sí tenía login.
Alcance: asegura la authn/authz de lo que el pedido crea o cambia. Huecos que veas en otras rutas van al reporte como riesgo, no al diff.
Primero, lo que ya existe
Lee cómo autentica el repo (proveedor, librería, middleware, RLS) y úsalo. No
introduzcas un segundo mecanismo ni una librería de auth nueva si ya hay una.
Si es Supabase, aplica además supabase.mdc. Nunca escribas tu propia crypto,
formato de token ni hashing.
Elegir mecanismo (solo si el repo no tiene uno)
| Caso | Usa |
| App web propia (mismo sitio) | Sesión en cookie HttpOnly; Secure; SameSite=Lax, id opaco, estado en servidor. Revocable al instante. |
| API consumida por móvil/terceros | Access token corto (5–15 min) + refresh token rotado. |
| "Entrar con Google/GitHub" | OIDC sobre OAuth2 Authorization Code + PKCE. Nunca el flujo implícito. |
| Empresa con IdP (Okta, Entra) | SSO por OIDC; SAML solo si el cliente lo exige. |
| Máquina a máquina | API key o client credentials, con scopes, rotables. |
Detalle de tokens, cookies, JWT y OIDC en references/tokens-and-sessions.md.
Reglas duras
- Authz en el servidor, en cada command y query, después de autenticar y
antes de tocar datos (
cqrs-data-flow: parsear → autorizar → ejecutar). Ocultar un botón no es authz. Middleware de ruta solo no alcanza. - Deny-by-default: sin regla explícita que permita, se niega. El recurso se
carga filtrando por dueño/tenant (
WHERE id = $1 AND tenant_id = $2) o por RLS; nunca por id solo (IDOR). - Roles y permisos en un solo módulo (
features/access/…o lo que use el repo):can(actor, action, resource). Nada deif (user.role === 'admin')disperso. - Tokens y secretos: nunca en
localStorage, logs, URLs ni mensajes de error. JWT se verifica (firma,algfijo,iss,aud,exp) en cada uso; decodificar no es verificar. - Contraseñas: argon2id (o bcrypt si el repo ya lo usa), nunca hash rápido ni reversible. Mensaje de error de login idéntico para usuario inexistente y contraseña mala. Rate limit por cuenta e IP.
- Cambios de privilegio (cambio de contraseña, email, rol, logout) invalidan sesiones y refresh tokens previos.
- Cookies con estado + formularios: protección CSRF (SameSite + token o
verificación de
Origin) en toda mutación. - Service keys / roles de servicio solo en servidor; nunca en el bundle del cliente.
Verificación (tests negativos obligatorios)
Por cada endpoint, command o policy tocada, al menos:
- Sin sesión/token →
UNAUTHENTICATED(401). - Otro usuario/tenant lee el recurso →
FORBIDDENoNOT_FOUND. - Otro usuario/tenant escribe o borra → rechazado y la fila no cambia.
- Rol insuficiente →
FORBIDDEN. - Token expirado, firma inválida o
audequivocado → rechazado. - Caso feliz del dueño → pasa.
Sin estos tests, reporta la authz como riesgo no verificado. Antes de cerrar,
pide hunter sobre el diff: authz e IDOR son su terreno.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.