Tema 9
Autenticarse no debería significar poder hacer cualquier cosa. La autorización define qué acciones, datos y recursos corresponden a cada identidad. Cuando este control falla, un usuario válido puede terminar accediendo a información ajena o ejecutando funciones para las que nunca tuvo permiso.
En muchas brechas reales el atacante no necesita romper una contraseña ni explotar una inyección. Le alcanza con autenticarse como un usuario legítimo y luego probar qué recursos o funciones puede alcanzar cambiando parámetros, URLs, identificadores o flujos.
Eso sucede cuando la aplicación asume que un usuario autenticado ya es confiable para todo, o cuando verifica permisos de manera incompleta. Desde la seguridad web, este problema es crítico porque suele afectar directamente datos sensibles, paneles administrativos, operaciones de negocio y privacidad de usuarios.
Por eso la autorización no puede ser un detalle añadido al final. Debe formar parte del diseño del sistema desde el principio.
La autenticación responde quién es el usuario. La autorización responde qué puede hacer ese usuario. Confundir ambos conceptos es una fuente muy común de vulnerabilidades.
Ejemplos típicos del error:
El control de acceso es el conjunto de reglas y mecanismos que determinan qué sujetos pueden acceder a qué recursos y bajo qué condiciones. En una aplicación web, esto se traduce en preguntas concretas:
Responder correctamente estas preguntas requiere mirar identidad, rol, propiedad del recurso, contexto del negocio y estado de la operación.
Las fallas de autorización suelen agruparse en varias categorías prácticas:
En todos estos casos, el problema no es la identidad principal del usuario, sino la decisión incorrecta sobre lo que se le permite hacer.
IDOR significa Insecure Direct Object Reference. Ocurre cuando la aplicación expone una referencia directa a un objeto interno, como un identificador de factura, pedido, documento o usuario, y no verifica correctamente si el solicitante tiene permiso para acceder a ese objeto específico.
El caso típico es simple: el usuario cambia un ID en la URL o en un parámetro y obtiene acceso a datos de otra persona. Pero el concepto se extiende a cualquier referencia directa manipulable sin un control de autorización apropiado.
IDOR aparece con frecuencia porque muchas aplicaciones construyen sus flujos alrededor de identificadores internos y luego se concentran en validar que el ID exista o tenga formato correcto, olvidando la pregunta realmente importante: ¿este usuario puede acceder precisamente a este recurso?
Además, es una vulnerabilidad fácil de pasar por alto porque el sistema puede “funcionar bien” en pruebas normales, pero fallar cuando alguien manipula parámetros fuera del flujo esperado.
| Escenario | Referencia manipulable | Consecuencia |
|---|---|---|
| Portal de clientes | ID de factura en la URL | Lectura de facturas ajenas |
| Aplicación educativa | ID de alumno o examen | Consulta o edición de datos de terceros |
| Panel interno | ID de ticket o expediente | Acceso a información sensible fuera del área permitida |
| API móvil | Identificador de recurso en JSON o path | Exposición masiva si se automatiza |
Un error muy común es pensar que si el identificador tiene formato correcto, el acceso es válido. Por ejemplo, comprobar que `pedido_id` sea un número positivo o un UUID bien formado no resuelve nada respecto de la autorización real.
La verificación correcta debe responder algo más profundo:
Existen varios enfoques para organizar permisos. Los más habituales son:
En la práctica, muchas aplicaciones usan una combinación de estos enfoques.
Dos principios ayudan mucho a diseñar autorización segura:
Estos principios reducen el riesgo de permisos heredados, funciones olvidadas o accesos ampliados por error con el crecimiento del sistema.
Ocultar botones, rutas o menús en el frontend puede mejorar experiencia y evitar confusiones, pero no constituye seguridad real. El atacante puede llamar directamente al endpoint, modificar la solicitud o usar herramientas automáticas sin pasar por la interfaz prevista.
Por eso las decisiones de autorización deben tomarse en el backend, para cada recurso y cada acción sensible.
Una aplicación segura no debería verificar permiso solo al entrar a una sección general del sistema. Debe comprobar también cada operación concreta sobre cada recurso concreto. Un usuario podría tener acceso al módulo de facturación, pero no por eso a todas las facturas existentes.
La regla práctica es simple: cada endpoint que devuelve o modifica datos debe validar autorización sobre ese dato exacto.
En APIs modernas el problema de autorización puede volverse aún más visible porque los endpoints suelen exponer recursos de forma directa y consumible por automatización. Si una API responde a IDs manipulables sin control fino, un atacante puede recorrer identificadores y extraer grandes volúmenes de información.
Esto obliga a revisar no solo el usuario autenticado, sino también el alcance del token, el rol, la propiedad del recurso y la respuesta devuelta.
Otra falla frecuente ocurre cuando funcionalidades administrativas están técnicamente presentes y accesibles, aunque la interfaz no las muestre a usuarios comunes. Si el endpoint existe y el backend no valida rol o permiso, la función queda expuesta.
Esto puede afectar aprobaciones, borrados, exportaciones, configuración del sistema o acceso a paneles internos.
La autorización no siempre depende solo del rol. También depende del momento y del estado del proceso. Por ejemplo:
Este tipo de lógica muestra que la seguridad también requiere entender bien el negocio.
Usar UUIDs u otros identificadores menos predecibles puede reducir exploración trivial, pero no resuelve por sí solo el problema de fondo. Si un usuario consigue una referencia válida de un recurso ajeno y el backend no verifica permiso, la vulnerabilidad sigue existiendo.
Los identificadores poco predecibles son una ayuda defensiva secundaria, no el control principal.
Imaginemos un portal médico donde cada paciente puede ver sus estudios mediante `/estudios?id=1234`. Si la aplicación solo verifica que el usuario tenga sesión y que el estudio exista, cambiar el número podría exponer resultados de otra persona.
La corrección real exige comprobar que ese estudio pertenece al paciente autenticado o que el profesional tiene permisos válidos sobre ese caso en particular.
Una estrategia madura suele combinar varias capas:
La autorización es el control que traduce identidad en límites concretos. Si esos límites están mal definidos o mal aplicados, incluso un usuario legítimo puede transformarse en la vía de una brecha grave. Por eso el control de acceso debe diseñarse con el mismo rigor que la autenticación.
En el próximo tema veremos manejo seguro de sesiones, cookies, tokens y cierre de sesión, porque una identidad bien autenticada y autorizada también necesita una sesión correctamente protegida.