Una API utiliza una pasarela, los usuarios disponen de tokens válidos y el tráfico está cifrado con HTTPS. Aun así, un empleado podría consultar el expediente de otro cliente. ¿Cómo es posible si el acceso parece protegido?
Imagina un portal ficticio. Un empleado puede leer el expediente 481, cambia su identificador por 482 en una solicitud y recibe datos de otra organización. El token es válido y la pasarela deja pasar la petición. Lo que falta es la comprobación de si esa persona tiene derecho a consultar ese expediente concreto.
Qué actualizó NIST en 2026
El National Institute of Standards and Technology publicó originalmente SP 800-228, Guidelines for API Protection for Cloud-Native Systems, en junio de 2025. El 13 de marzo de 2026 añadió dos anexos sobre categorías de riesgos de API y medidas recomendadas a lo largo del ciclo de vida. La guía propone decisiones basadas en riesgos y no exige un proveedor específico de pasarelas.
Un token válido no concede acceso al expediente 482
Una pasarela puede enrutar tráfico, proteger conexiones y limitar solicitudes. El proveedor de identidad gestiona usuarios y credenciales. Pero ninguno conoce automáticamente los permisos sobre cada registro. OWASP describe Broken Object Level Authorization (BOLA): poder utilizar un endpoint no significa tener derecho a todos los objetos identificables.
En plataformas multi-tenant, la aplicación debe comprobar a qué organización pertenece el registro, de dónde procede ese contexto y si quien realiza la petición puede manipularlo. Un ID de organización recibido en un parámetro no fiable no demuestra autorización. La protección no puede depender solo de ocultar opciones en el frontend.
Una ruta protegida no garantiza toda la API
La consulta individual puede comprobar permisos, mientras que búsquedas, listas, exportaciones masivas o versiones antiguas exponen los mismos datos por otras rutas. También las respuestas de error pueden revelar información. Cada operación relevante debe aplicar permisos sobre los objetos y organizaciones.
Las reglas de negocio son otra frontera
Un empleado puede estar autorizado a leer un expediente y no a modificarlo cuando está cerrado. Una solicitud de pago duplicada puede necesitar idempotencia y controles transaccionales. No es el mismo problema que BOLA, pero muestra que autenticación, autorización y reglas de negocio cumplen funciones diferentes. Limitar solicitudes no sustituye esos controles.
Comprueba lo que debe rechazarse
En un entorno de pruebas, crea dos usuarios de organizaciones distintas. Con el token del primero, intenta leer, modificar y exportar un registro del segundo. Comprueba la denegación, que no se filtren datos en errores o logs y que la base de datos no cambie. Repite con tokens caducados, permisos revocados, filtros de búsqueda y solicitudes repetidas. Documenta qué capa debe rechazar cada operación.
Más capas no implican automáticamente más seguridad
Otra pasarela puede centralizar reglas, pero también añade configuración y mantenimiento. Una API interna pequeña tiene riesgos distintos a una plataforma pública multi-tenant. Registra responsables, pruebas, rotación de credenciales y vigilancia de incidentes, evitando almacenar secretos o datos personales innecesarios.
La protección se demuestra al rechazar una solicitud válida
Lo decisivo no es que un token pase la pasarela, sino que se rechace una acción sin permiso. La seguridad de una API depende de responsabilidades comprobables, no del número de productos instalados.
mantenimiento y deuda técnica.
Fuentes
Contacta con nosotros
Cuéntanos cómo podemos ayudarte; responderemos en un plazo de dos días laborables.
