API3:2023 – Broken Object Property Level Authorization
Este riesgo ocurre cuando una API sí valida el acceso al objeto, pero no controla qué propiedades de ese objeto puede ver o modificar el usuario. El resultado es que la API devuelve (o acepta) más campos de los permitidos, exponiendo información sensible o habilitando cambios indebidos dentro de un mismo recurso.
Origen del problema
Aparece con frecuencia por prácticas comunes en el desarrollo de APIs:
- Respuestas genéricas: se reutiliza el mismo modelo de respuesta para distintos roles (usuario, operador, admin).
- Falta de filtrado por rol o contexto: la API no oculta campos según permisos específicos.
- Evolución del producto: se agregan nuevos campos sensibles y se olvidan controles finos por propiedad.
- Confianza en el front-end: se asume que “si no se muestra en pantalla, no se expone”, aunque la API lo envíe igual.
- Complejidad del negocio: estados internos, flags, límites o notas internas no se separan del modelo público.
Ejemplo de escenario de ataque
Paso 1 – Contexto del sistema
Una plataforma de e-commerce expone una API para consultar pedidos. Los clientes pueden ver el estado y el total de sus compras. Internamente, cada pedido también tiene campos como descuento interno, estado antifraude y margen comercial.
Paso 2 – Acción general del atacante
Un cliente legítimo consulta sus pedidos. La API valida correctamente que el pedido le pertenece, pero no filtra las propiedades devueltas y responde con todos los campos, incluidos los internos.
Paso 3 – Resultado o impacto
El cliente obtiene información que no debería conocer (reglas internas, márgenes, flags de riesgo). Esto puede facilitar abusos, ingeniería social o manipulación de procesos comerciales.
Impacto real si no se gestiona
- Exposición de información sensible (márgenes, flags internos, estados de riesgo).
- Ventaja indebida para usuarios al conocer reglas internas del negocio.
- Riesgo de fraude y abuso al entender cómo funcionan controles internos.
- Incumplimientos contractuales o regulatorios por sobreexposición de datos.
- Pérdida de confianza al revelar información que “no debía salir”.
Conclusión
Este riesgo no suele sentirse como “brecha”, sino como “detalle”: un campo de más aquí, una propiedad interna allá. El problema es que esos “detalles” son exactamente lo que un atacante necesita para entender tu negocio por dentro y abusarlo con ventaja.
¿Quieres profundizar en el OWASP API Top 10:2023?
Domina los 10 riesgos más críticos de las APIs de forma práctica con mi curso OWASP API Top 10:2023, actualizado a la última versión.
Nos vemos en la siguiente entrada
Fernando Conislla
