Tu API reconoce al usuario, pero ¿comprueba qué puede hacer con cada dato?

Una API puede exigir inicio de sesión y seguir permitiendo acceder a datos que pertenecen a otra persona o a otra unidad. El fallo aparece cuando el servidor identifica al usuario, pero acepta un identificador de recurso sin comprobar si esa operación está permitida. OWASP incluye la autorización incorrecta a nivel de objeto entre los riesgos de su API Security Top 10 de 2023. Corregirla exige diseñar reglas sobre los datos, además de proteger el mecanismo de autenticación.

Separa identidad, objeto y acción

La autenticación responde a quién realiza la petición. La autorización debe resolver si esa identidad puede ejecutar una acción sobre un recurso concreto y bajo qué condiciones. Un usuario puede leer una solicitud propia y no modificarla después de su aprobación. Un responsable puede consultar solicitudes de su equipo, pero no las de otro. Escribe estas reglas en una matriz pequeña que incluya función, relación con el objeto y estado del proceso. Así se evita reducir todo a una etiqueta genérica de usuario autenticado.

No confíes en los filtros de la interfaz

Ocultar botones o retirar opciones mejora la experiencia, pero la API debe aplicar las mismas reglas de forma independiente. Los identificadores pueden llegar en la ruta, en parámetros, en el cuerpo de la petición o dentro de una operación masiva. Usar valores difíciles de adivinar no sustituye la comprobación de permisos. La recomendación de OWASP es validar la autorización en las funciones que acceden a objetos mediante identificadores proporcionados por el cliente, considerando la acción solicitada y el recurso afectado.

Conviene que las consultas incorporen el ámbito autorizado en vez de recuperar todo y confiar en una comprobación posterior dispersa. Esto no elimina la necesidad de revisar reglas complejas, pero reduce oportunidades de olvido. Centraliza políticas reutilizables cuando varias rutas comparten una decisión, y mantén explícitas las excepciones. Una abstracción demasiado general también puede ocultar qué se está autorizando realmente.

Protege campos y cambios de estado

Tener acceso a un objeto no implica poder leer o modificar todos sus atributos. Una respuesta puede incluir campos internos que la pantalla no muestra; una actualización puede aceptar propiedades que el formulario nunca envía. Define listas de campos permitidos para cada operación y revisa transiciones sensibles, como cambiar responsable, ámbito o estado. No asignes directamente todo el cuerpo recibido a una entidad persistida. La validación de formato y la autorización de una modificación son comprobaciones diferentes y ambas resultan necesarias.

Incluye rutas que suelen quedar fuera de la revisión

Exportaciones, búsquedas, adjuntos y operaciones por lotes deben respetar el mismo alcance que la vista principal. Comprueba también servicios internos y tareas en segundo plano que actúan en nombre de usuarios. Un enlace de descarga no debería permitir recuperar un documento fuera del permiso previsto. Decide cómo se gestionan enlaces temporales, cachés y respuestas ya generadas cuando cambia una autorización. La política debe abarcar todo el recorrido del dato, no solamente el endpoint más visible.

• Prepara dos usuarios con el mismo rol y recursos en ámbitos diferentes.
• Comprueba lectura, modificación y eliminación de objetos autorizados y ajenos.
• Incluye propiedades sensibles y transiciones de estado en los casos negativos.
• Revisa búsquedas, exportaciones, adjuntos y operaciones masivas.
• Verifica que los fallos de autorización no dejan efectos parciales ni filtran detalles sensibles.

Prueba la regla con escenarios negativos

Una prueba que confirma el acceso permitido cubre solo la mitad del contrato. Añade intentos legítimos de prueba con una cuenta sin permiso y verifica la respuesta y la ausencia de cambios. Define una política consistente para recursos inexistentes y no autorizados, evitando revelar más información de la necesaria. También hay que probar cambios simultáneos: un permiso o estado puede variar entre la lectura inicial y la escritura. Las comprobaciones críticas deben mantenerse válidas en el momento de aplicar la operación.

Mantén las reglas cuando evoluciona el producto

Cada nueva función, rol o integración puede alterar supuestos anteriores. Incluye la revisión de permisos en el diseño de cambios que exponen o modifican datos. Registra denegaciones relevantes con contexto suficiente para investigar patrones, sin guardar tokens ni contenido sensible. Revisa las excepciones y elimina accesos temporales cuando dejan de ser necesarios. Una API protegida no depende de que el cliente se comporte como espera la interfaz: mantiene sus decisiones de acceso de forma comprobable en cada operación.