3. A01: Broken Access Control

3.1 Introducción

En la mayoría de las aplicaciones hay recursos y acciones que no deben estar disponibles para todos por igual. Un usuario puede ver su propio perfil, pero no el de otra persona. Un cliente puede consultar sus pedidos, pero no los pedidos ajenos. Un operador puede aprobar ciertas acciones, mientras que un administrador puede gestionar cuentas, configuraciones y reportes globales.

El mecanismo que define y aplica esas restricciones es el control de acceso. Cuando la aplicación lo implementa de forma incompleta, inconsistente o directamente incorrecta, aparecen fallas de autorización que permiten a un atacante leer datos indebidos, modificar información ajena, ejecutar acciones privilegiadas o tomar control de partes críticas del sistema.

OWASP ubica Broken Access Control como A01 porque es una categoría extremadamente frecuente y con impactos severos. Además, suele ser silenciosa: la aplicación puede seguir funcionando aparentemente bien mientras permite accesos que nunca debieron ocurrir.

3.2 Qué es el control de acceso

El control de acceso es el conjunto de reglas y mecanismos que determinan qué acciones puede realizar cada identidad sobre cada recurso del sistema.

Responder correctamente estas preguntas es parte del control de acceso:

• ¿Este usuario puede ver este registro?
• ¿Puede editarlo o eliminarlo?
• ¿Puede acceder a esta URL o endpoint?
• ¿Puede ejecutar esta acción administrativa?
• ¿Puede invocar esta función en este contexto?
• ¿Puede operar sobre este objeto específico o solo sobre los propios?

En otras palabras, autenticación responde quién eres, mientras que control de acceso responde qué te está permitido hacer.

3.3 Autenticación no es autorización

Una confusión muy común es asumir que, si un usuario inició sesión correctamente, entonces ya puede acceder a todo lo que vea o intente. Eso es falso. La autenticación solo prueba identidad. La autorización decide los permisos concretos.

Ejemplo: dos usuarios pueden estar autenticados con éxito en la misma aplicación, pero uno debe poder ver únicamente su factura y el otro no debe verla. Si la aplicación no diferencia ese permiso por recurso, hay una falla de control de acceso.

3.4 Qué significa Broken Access Control

Broken Access Control describe cualquier situación en la que la aplicación no aplica correctamente restricciones de acceso. El problema puede aparecer porque faltan verificaciones, porque se aplican solo en la interfaz visual, porque dependen de datos manipulables o porque no contemplan todos los escenarios.

Algunas manifestaciones típicas son:

• Acceder a objetos de otros usuarios cambiando un identificador.
• Entrar a funciones administrativas sin tener rol suficiente.
• Invocar endpoints internos que la interfaz normal no muestra.
• Modificar parámetros que controlan privilegios o pertenencia.
• Usar métodos HTTP alternativos para evadir restricciones.
• Saltarse pasos de un flujo para ejecutar acciones no autorizadas.

3.5 Tipos de control de acceso

No todo control de acceso es igual. En una aplicación real suelen convivir varios niveles de restricción.

Las fallas pueden aparecer en cualquiera de estos niveles. Una aplicación puede proteger menús administrativos y aun así dejar expuesto el acceso por objeto.

3.6 Escalación horizontal y vertical

Dos conceptos ayudan a clasificar muchas fallas de autorización.

• Escalación horizontal: el usuario accede a recursos o datos de otro usuario con privilegio similar. Ejemplo: un cliente ve la factura de otro cliente.
• Escalación vertical: el usuario obtiene capacidades de un rol superior. Ejemplo: un usuario común accede a funciones de administrador.

Ambas son graves. La horizontal suele exponer privacidad y datos. La vertical puede conducir al control total de la aplicación.

3.7 IDOR y BOLA: ejemplos muy comunes

Uno de los casos más conocidos de Broken Access Control es IDOR, Insecure Direct Object Reference. En APIs también se usa el término BOLA, Broken Object Level Authorization. La idea central es la misma: la aplicación permite acceder a un objeto solo cambiando su identificador, sin verificar si ese objeto pertenece realmente al usuario actual.

Ejemplo simple:

• Un usuario consulta /pedido/123 y ve su pedido.
• Cambia manualmente la URL a /pedido/124.
• Si el sistema muestra otro pedido sin validar propietario, existe una falla de acceso por objeto.

Este problema es especialmente peligroso porque suele parecer trivial desde lo técnico, pero permite exfiltrar datos de múltiples usuarios con un esfuerzo mínimo.

3.8 Por qué estas fallas son tan frecuentes

Broken Access Control aparece con mucha frecuencia porque el permiso correcto depende de la lógica del negocio y de cada recurso concreto. No basta con "tener login" o con ocultar botones en la interfaz.

Entre las causas más habituales se encuentran:

• Verificar permisos solo en el frontend.
• No aplicar controles en todos los endpoints equivalentes.
• Confiar en parámetros enviados por el cliente.
• Suponer que un identificador difícil de adivinar es suficiente.
• Falta de un modelo centralizado de autorización.
• Complejidad creciente de roles, estados y excepciones.
• Reutilización de código sin revisar impacto en permisos.

3.9 Ocultar no es proteger

Un error muy común consiste en esconder botones, menús o enlaces y asumir que eso ya impide el acceso. Desde seguridad, eso no alcanza. Cualquier persona puede intentar llegar directamente a una URL, invocar un endpoint o modificar una solicitud manualmente.

Por eso los controles de acceso deben aplicarse siempre del lado servidor. La interfaz puede ayudar a no mostrar acciones no disponibles, pero la autoridad final debe estar en la lógica de backend.

3.10 Ejemplos típicos de Broken Access Control

• Editar el perfil de otro usuario cambiando un parámetro user_id.
• Descargar documentos ajenos mediante URLs predecibles.
• Acceder a /admin porque la ruta existe y no valida rol.
• Invocar directamente un endpoint de borrado que la interfaz no expone.
• Cambiar el rol en un formulario oculto y que el backend lo acepte.
• Usar DELETE donde la interfaz solo permitía GET o POST.
• Consultar datos históricos o archivados sin verificar pertenencia.

Todos estos casos comparten la misma raíz: la aplicación no decide permisos de forma confiable sobre cada recurso y acción.

3.11 El problema de confiar en identificadores

Muchas aplicaciones trabajan con identificadores numéricos, UUID, códigos o claves internas para referenciar objetos. Estos identificadores son necesarios, pero no constituyen autorización.

Un error común es pensar:

• Si el identificador es largo o aleatorio, ya está protegido.
• Si nadie enlaza esa URL, nadie la encontrará.
• Si el usuario "no sabe" otros IDs, el riesgo es bajo.

Todo eso es insuficiente. El backend debe verificar explícitamente que el objeto solicitado pertenece al usuario actual o que su rol le permite operar sobre él. La autorización nunca debe derivarse solo del identificador recibido.

3.12 Control de acceso a nivel de función

Algunas fallas no implican acceso a objetos ajenos, sino a funcionalidades completas que deberían estar restringidas. Esto ocurre cuando un usuario común alcanza endpoints o pantallas reservadas para roles de mayor privilegio.

Ejemplos:

• Un usuario estándar accede al listado global de clientes.
• Un operador puede asignarse permisos administrativos.
• Un empleado puede exportar reportes financieros sin autorización.

Este problema suele surgir cuando las rutas administrativas existen pero solo se ocultan visualmente, o cuando el sistema reutiliza componentes sin revalidar el rol requerido.

3.13 Control de acceso a nivel de objeto

El acceso a nivel de objeto es el que define si una identidad puede operar sobre una instancia específica. Por ejemplo, no alcanza con permitir "ver facturas"; hay que decidir qué facturas puede ver cada usuario.

Este tipo de validación suele ser más delicado porque depende de relaciones concretas de pertenencia, propiedad, jerarquía o delegación.

Buenas preguntas de diseño:

• ¿Este recurso pertenece al usuario?
• ¿El usuario actúa en nombre de otra entidad autorizada?
• ¿El rol le permite ver objetos ajenos o solo propios?
• ¿Hay estados especiales que cambian quién puede operar?

3.14 Flujos de negocio y bypass de pasos

No todas las fallas de autorización aparecen en una única solicitud. A veces el problema está en permitir que el usuario salte pasos de un proceso que debería estar encadenado y controlado.

Ejemplos:

• Aprobar una operación sin haber pasado por revisión previa.
• Confirmar una compra sin completar validaciones obligatorias.
• Cancelar una orden ya enviada porque el backend no revisa el estado actual.

Este tipo de fallo muestra que el control de acceso también depende del contexto, no solo del rol o del ID del recurso.

3.15 Impacto de Broken Access Control

El impacto puede ser muy alto porque esta categoría afecta directamente quién puede hacer qué dentro de la aplicación. Si la respuesta es incorrecta, la seguridad del sistema se rompe en su esencia.

3.16 Señales que pueden indicar esta vulnerabilidad

Durante un análisis de seguridad, algunos indicios sugieren revisar con más detalle el control de acceso:

• Identificadores visibles y modificables en URL o cuerpos JSON.
• Rutas administrativas accesibles directamente.
• Diferencia entre lo que la interfaz muestra y lo que el backend realmente permite.
• Respuestas exitosas al cambiar IDs de recursos.
• Falta de mensajes de autorización explícitos en acciones sensibles.
• Roles complejos sin una matriz clara de permisos.
• Endpoints de API con mucho poder y poco contexto de validación.

3.17 Ejemplo conceptual de IDOR

Supongamos que una aplicación bancaria permite ver extractos con una URL como /extracto?id=8452. El usuario autenticado accede a su propio documento. Luego cambia el valor a 8453.

Si el sistema solo hace algo como "buscar extracto por id y mostrarlo", sin validar que ese extracto pertenece al usuario actual, se produce una exposición de información. Técnicamente el fallo parece simple, pero el impacto es muy serio porque rompe el aislamiento entre cuentas.

Este mismo patrón se repite en APIs, paneles internos, reportes PDF, tickets, documentos, historiales, conversaciones y muchos otros objetos.

3.18 Causas de diseño e implementación

Broken Access Control puede originarse tanto en el diseño como en la implementación.

• Problema de diseño: no se definió claramente qué roles existen ni qué permisos tiene cada uno.
• Problema de implementación: las reglas existen, pero no se aplican en todos los puntos necesarios.
• Problema de consistencia: una misma función tiene controles distintos según la ruta o el método.
• Problema de mantenimiento: se agregaron nuevas funciones sin incorporar verificaciones adecuadas.

Por eso esta categoría no se corrige solo con un parche puntual. Muchas veces exige revisar cómo piensa la aplicación sus permisos de forma integral.

3.19 Buenas prácticas de prevención

Prevenir Broken Access Control exige disciplina de arquitectura y de desarrollo.

• Aplicar autorización del lado servidor en cada solicitud relevante.
• Negar por defecto y permitir solo lo explícitamente habilitado.
• Centralizar reglas de autorización en lugar de dispersarlas.
• Verificar acceso por objeto, no solo por rol general.
• No confiar en IDs, parámetros ocultos ni datos del cliente para decidir permisos.
• Separar claramente funciones públicas, privadas y administrativas.
• Registrar intentos de acceso rechazados y acciones sensibles.

3.20 Diseñar con mínimo privilegio

El principio de mínimo privilegio indica que cada usuario, servicio o rol debe tener solo los permisos estrictamente necesarios para cumplir su función. Esto reduce impacto en caso de error o abuso.

Aplicado a aplicaciones web, implica:

• Evitar roles excesivamente poderosos.
• No otorgar privilegios globales cuando basta con privilegios locales.
• Separar tareas administrativas entre perfiles distintos cuando sea posible.
• Limitar operaciones destructivas o de alto impacto.

3.21 Matriz de permisos y revisión sistemática

Una forma útil de reducir errores es documentar una matriz de permisos. Esto obliga a explicitar quién puede hacer qué sobre cada recurso.

Una matriz puede responder:

• Qué roles existen.
• Qué acciones permite cada rol.
• Sobre qué objetos puede operar.
• Qué condiciones de estado modifican ese permiso.

Cuando esto no está documentado, es fácil que distintas partes del sistema implementen criterios diferentes y aparezcan inconsistencias.

3.22 Pruebas para detectar esta categoría

La detección de Broken Access Control requiere probar la aplicación desde distintos perfiles y manipular solicitudes de forma deliberada.

• Acceder a recursos cambiando identificadores.
• Probar endpoints directamente sin pasar por la interfaz.
• Intentar funciones administrativas con cuentas de menor privilegio.
• Usar distintos métodos HTTP sobre la misma ruta.
• Modificar parámetros relacionados con usuario, rol, estado o pertenencia.
• Repetir acciones en distintas etapas del flujo para buscar bypasses.

Estas pruebas suelen ser más efectivas cuando se combinan con buen entendimiento del negocio y no solo con escaneo automático.

3.23 Errores frecuentes en la remediación

• Corregir una ruta puntual y dejar otras equivalentes sin protección.
• Agregar validación solo en frontend.
• Ocultar enlaces en vez de reforzar backend.
• Confiar en identificadores opacos como si fueran autorización suficiente.
• Validar rol general pero no propiedad del objeto.
• No revisar APIs, exportaciones y descargas de archivos.

3.24 Relación con otras vulnerabilidades

Broken Access Control suele combinarse con otras categorías del curso.

• Con fallas de autenticación, si un atacante secuestra una sesión y luego explota permisos mal aplicados.
• Con exposición de datos, si la autorización débil revela información sensible.
• Con diseño inseguro, cuando el flujo de negocio permite abusos estructurales.
• Con logging insuficiente, si los accesos indebidos pasan inadvertidos.

Esto explica por qué A01 es tan crítica: no solo es grave por sí misma, sino que potencia otras debilidades.

3.25 Qué debes recordar de este tema

• Autenticación y autorización son problemas distintos.
• Broken Access Control ocurre cuando la aplicación permite acciones o accesos que no corresponden.
• IDOR y BOLA son ejemplos clásicos de acceso indebido a objetos.
• Ocultar botones o rutas no reemplaza controles del lado servidor.
• La autorización debe verificarse por función, por objeto y por contexto.
• El principio de mínimo privilegio reduce la superficie de impacto.
• La prevención requiere reglas claras, centralizadas y verificadas en cada solicitud.

3.26 Conclusión

Broken Access Control es una de las fallas más peligrosas en seguridad web porque ataca directamente el mecanismo que separa lo permitido de lo prohibido dentro de la aplicación. Cuando esa barrera falla, el atacante ya no necesita técnicas especialmente complejas: la propia lógica del sistema le abre el camino.

En el próximo tema estudiaremos A02: Cryptographic Failures, centrado en cómo se protegen o se exponen los datos sensibles cuando el cifrado, el transporte o el almacenamiento se implementan de forma incorrecta.