Autenticación y autorización

“Comprobar que alguien tiene una entrada, pero nunca comprobar que es una entrada para este asiento.”

Autenticación no es autorización

Dos preguntas distintas se esconden tras "auth". La autenticación pregunta quién eres, demostrado con un login. La autorización pregunta qué tienes permitido tocar, decidido por petición, por recurso. Son independientes: estar conectado (autenticado) no dice nada sobre si puedes leer el pedido #124 (autorización). Las herramientas de IA clavan la primera porque es visible y se pide en el prompt. Fallan la segunda porque, con un solo usuario de prueba que lo posee todo, nunca sale a relucir.

El resultado es una app donde iniciar sesión es sólido y, una vez dentro, puedes alcanzar los datos de todo el mundo. La puerta principal tiene una buena cerradura; ninguna de las puertas interiores la tiene.

El bug que tendrás de verdad: IDOR

Insecure Direct Object Reference es el nombre poco glamuroso del fallo más probable de tu app. El patrón: un recurso se direcciona por un id, y el servidor se lo devuelve a cualquiera autenticado, sin comprobar la propiedad. Tu UI solo te enlaza a tus propios registros, así que parece correcto, pero el id de la URL o de la llamada a la API es solo un número, y cambiarlo devuelve el de otra persona.

  posees el pedido 123
  GET /api/orders/123   →  200  { tu pedido }        ✓ correcto
  GET /api/orders/124   →  200  { el de otro }       ✗ IDOR: sin comprobar propiedad
                           ^ lo único que cambiaste fue un número

Es trivial de encontrar y trivial de explotar: incrementa un id, lee la factura de un desconocido. Y está por todas partes en las apps construidas con IA, porque el endpoint generado recupera el registro por id y lo devuelve; la línea "¿este usuario es su dueño?" es la salvaguarda invisible que nadie pidió. Una comprobación de propiedad que aguanta.↗

El auth se degrada mientras haces prompting

Un fallo más sutil: una guarda que añadiste en un prompt desaparece en otro posterior sin relación. Le pides a la herramienta que "añada filtrado a este endpoint", reescribe el handler, y la comprobación de propiedad que estaba ahí se esfuma en silencio, porque el modelo regeneró la función alrededor de la nueva petición y no arrastró la restricción anterior. El endpoint sigue devolviendo datos, la demo sigue funcionando, y el agujero se reabrió sin dejar rastro.

Por eso la seguridad en apps construidas con IA no puede ser una pasada única. Las comprobaciones decaen cada vez que regeneras código a su alrededor. Se re-verifica después de los cambios, que es exactamente para lo que sirve la checklist del capítulo 6.

La regla: comprobar en el servidor, cada vez

Toda defensa aquí se reduce a una disciplina: el servidor decide, en cada petición, usando valores que el cliente no puede falsificar:

• Autentica cada petición protegida en el servidor; nunca infieras la identidad de algo enviado por el cliente.
• Autoriza por recurso: ¿ESTE usuario autenticado posee (o tiene un rol que le concede) ESTA fila concreta? No solo "¿está conectado?".
• Nunca confíes en un user_id, rol o flag is_admin suministrado por el cliente; deriva identidad y permisos de la sesión verificada.
• Denegar por defecto: si ninguna regla concede acceso explícitamente, rechaza. Prefiere devolver 404 antes que 403 para no confirmar siquiera que el recurso existe.

Es el mismo principio que la Row-Level Security del capítulo 2, aplicado en la capa de aplicación en lugar de la base de datos. De hecho, se refuerzan mutuamente: RLS atrapa lo que deja pasar una comprobación de aplicación omitida, y viceversa. Defensa en profundidad significa que quieres ambas.