Proteja una API con datos regulados modelando quién podría hacer un mal uso de ella, comprobando la autorización en cada objeto y en cada campo, recogiendo y devolviendo el mínimo de datos posible y manteniendo bajo estricto control los secretos y los registros de auditoría. En la práctica, los puntos débiles que más importan son los fallos de autorización y las respuestas que exponen demasiados datos, no un cifrado roto.
Empiece por un modelo de amenazas de los datos, no del framework
Antes de elegir herramientas, ponga por escrito lo que expone la API y quién podría hacer un mal uso de ella. En un banco, eso significa datos de cuentas y de transacciones; en una empresa energética o de servicios públicos, puede significar datos de contadores, contratos de clientes y lecturas operativas de la red.
Un modelo de amenazas útil es breve. Enumera los datos sensibles, cada consumidor que puede acceder a ellos, las acciones que cada uno debería poder realizar y lo que ocurre si uno de ellos se ve comprometido. Ese documento guía después todos los controles siguientes y dice a los revisores qué deben probar.
- Qué datos son personales, confidenciales o regulados, y dónde se almacenan.
- Cada consumidor de la API: servicios internos, socios, apps móviles y administradores.
- Lo que cada consumidor puede leer, modificar o desencadenar.
- El impacto de un token filtrado, de una persona interna malintencionada o del sistema comprometido de un socio.
Autentique a cada consumidor y después autorice cada objeto
Use un protocolo estándar como OAuth 2.0 con OpenID Connect para los usuarios, y tokens de corta duración o TLS mutuo para las llamadas entre servicios. Evite las claves de API compartidas y de larga duración, porque nadie puede saber qué sistema las usó ni revocarlas sin afectar a otros.
La autenticación solo demuestra quién llama. La primera entrada del OWASP API Security Top 10 es la autorización rota a nivel de objeto: un usuario válido cambia un identificador en la petición y lee el registro de otra persona. Compruebe en el servidor la propiedad o el tenant de cada objeto, de cada función y de cada campo sensible, y no confíe nunca en un identificador o un rol enviado por el cliente.
Dé a cada cliente y servicio el mínimo privilegio que necesita
El mínimo privilegio limita los daños cuando algo sale mal. Emita credenciales distintas por consumidor, limite los tokens a operaciones concretas y mantenga los endpoints de administración en una ruta separada con comprobaciones más estrictas.
Aplique la misma regla por debajo de la API. La cuenta de servicio que lee los datos de los contadores no debería poder borrarlos, y un proceso de informes debería conectarse con un rol de base de datos de solo lectura. Revise los permisos periódicamente, porque el acceso concedido para una tarea puntual tiende a quedarse para siempre.
Recoja menos, devuelva menos y consérvelo menos tiempo
La minimización de datos es a la vez un principio del RGPD y un control de seguridad eficaz: los datos que nunca almacena no pueden filtrarse. Pregúntese por cada campo si el servicio lo necesita de verdad, y elimine o seudonimice lo que no.
Aplique la misma disciplina a las respuestas. Defina esquemas de respuesta explícitos en lugar de serializar objetos completos de la base de datos, enmascare identificadores como los números de cuenta cuando no haga falta el valor completo y fije plazos de conservación para que se borren los registros antiguos. Documente la base jurídica de cada finalidad del tratamiento y firme contratos de encargo del tratamiento con cualquier proveedor que maneje los datos. Esto es práctica de ingeniería, no asesoramiento jurídico, así que implique a su delegado de protección de datos o a sus asesores jurídicos para la evaluación legal.
Valide cada entrada y limite el consumo de cada cliente
Trate cada petición como hostil hasta validarla. Imponga un esquema para cada endpoint, rechace los campos desconocidos y use consultas parametrizadas para que la entrada nunca forme parte de un comando de base de datos.
Varios riesgos de OWASP para las API vienen de límites que faltan más que de código defectuoso. Limite la tasa de peticiones por cliente, ponga un tope al tamaño de las páginas y de las cargas útiles, y proteja los flujos de negocio sensibles, como los pagos o los cambios de contrato, frente al abuso automatizado. Si la API obtiene URL remotas en nombre de quien llama, restrinja los destinos para evitar la falsificación de peticiones del lado del servidor (SSRF).
Mantenga los secretos fuera del código, las imágenes y los logs
Las contraseñas de bases de datos, las claves de firma y las credenciales de los socios deben estar en un gestor de secretos dedicado, inyectarse en tiempo de ejecución y rotarse periódicamente. Analice los repositorios y las imágenes de contenedor en busca de secretos en el pipeline de compilación, y dé por comprometido cualquier secreto que llegue al control de versiones.
Separe los secretos por entorno para que una credencial de pruebas filtrada nunca abra la producción. Restrinja quién puede leer los secretos en producción y registre cada acceso a ellos.
Registre para auditar y diseñe para tener menos incidencias
Los entornos regulados deben poder responder a posteriori a una pregunta sencilla: quién accedió a qué datos, cuándo y a través de qué cliente. Regístrelo en cada lectura y escritura sensible, guarde los logs donde los operadores de la aplicación no puedan alterarlos y mantenga los datos personales fuera de los mensajes de log.
Combine los logs con alertas ante patrones inusuales, como un cliente que lee muchos más registros de lo habitual, y con un plan de respuesta a incidentes probado. A través de Sopra Steria, nuestros ingenieros construyeron API seguras para datos sensibles de servicios públicos con restricciones regulatorias y dirigieron una herramienta de supervisión operativa en la que la aplicación de estándares de seguridad fue de la mano de menos incidencias en producción. SDK Enterprises aplica hoy las mismas prácticas a los proyectos de sus clientes.
Puntos clave
- Un modelo de amenazas de los datos, breve y por escrito, debe guiar cada control de seguridad de la API.
- Compruebe la autorización en el servidor para cada objeto, función y campo sensible, no solo al iniciar sesión.
- El mínimo privilegio se aplica por igual a los tokens, a las cuentas de servicio y a los roles de base de datos.
- La minimización de datos reduce tanto la exposición en materia de RGPD como el impacto de cualquier brecha.
- Los registros de auditoría deben mostrar quién accedió a qué y cuándo, sin filtrar ellos mismos datos personales.
Preguntas frecuentes
¿Basta HTTPS para proteger una API?
No. TLS protege los datos en tránsito, pero muchas brechas en API implican a usuarios autenticados que acceden a datos que no deberían ver. Siguen haciendo falta comprobaciones de autorización, validación de entradas, límites de peticiones y registros de auditoría.
¿Qué es la autorización rota a nivel de objeto?
Es un fallo en el que la API comprueba que quien llama ha iniciado sesión, pero no que el registro solicitado le pertenezca. Basta entonces con cambiar un identificador en la URL o en el cuerpo de la petición para ver los datos de otros usuarios. La solución es comprobar en el servidor la propiedad o el tenant de cada objeto.
¿Impone el RGPD controles de seguridad concretos para las API?
El RGPD exige medidas técnicas y organizativas apropiadas al riesgo, sin imponer herramientas concretas. Controles como la restricción de accesos, la minimización, la seudonimización y los registros son formas habituales de cumplir ese requisito, y sus asesores jurídicos deberían confirmar qué se aplica a su caso.