La seguridad de una API comienza antes de escribir código
Podemos agregar autenticación, cifrado, tokens y un API gateway; aun así, la API puede seguir siendo insegura si nunca definimos qué debemos proteger, quién puede hacer qué y qué ocurriría si alguno de nuestros supuestos falla. En este artículo reflexiono sobre activos, amenazas, autorización, disponibilidad y responsabilidad organizacional. Los invito a leer “La seguridad de una API comienza antes de escribir código”.
Autenticar solicitudes no compensa no haber entendido qué debemos proteger
A lo largo de mi carrera he visto proyectos en los que la conversación sobre seguridad comienza demasiado tarde.
Primero se define la funcionalidad. Después se construyen los endpoints, se conectan las bases de datos y se realizan las integraciones. Cerca de la fecha de liberación, alguien formula la pregunta inevitable:
¿Cómo vamos a asegurar la API?
Entonces aparecen las respuestas conocidas: agregar autenticación, habilitar HTTPS, generar tokens, configurar permisos y colocar un API gateway.
Todas esas medidas pueden ser necesarias. Ninguna corrige por sí misma una decisión insegura de diseño.
Podemos proteger una API con autenticación robusta y, aun así, permitir que un usuario consulte información que no le corresponde. Podemos cifrar el tráfico y conservar datos que nunca debimos exponer. Podemos validar un token correctamente y autorizar una operación que viola una regla del negocio.
La seguridad no comienza eligiendo mecanismos.
Comienza entendiendo qué debemos proteger, de quién, bajo qué circunstancias y con qué consecuencias si fallamos.
Antes de proteger, debemos identificar los activos
Neil Madden plantea en API Security in Action que una definición útil de seguridad comienza identificando los activos del sistema.
Esto parece evidente hasta que intentamos hacerlo.
En una API educativa, por ejemplo, los activos no son solamente las bases de datos o las credenciales de acceso. También pueden incluir:
- Datos personales de estudiantes y colaboradores.
- Información académica y financiera.
- Documentos e identificaciones.
- Tokens, llaves y certificados.
- Reglas de autorización.
- Historial de transacciones.
- Evidencia de consentimientos.
- Integridad de calificaciones, pagos o inscripciones.
- Disponibilidad de servicios críticos.
- Reputación y confianza institucional.
Algunos activos son información. Otros son capacidades.
La posibilidad de registrar un pago, modificar un expediente, activar una cuenta o emitir un documento también debe protegerse. Aunque una operación no revele datos sensibles, su uso indebido puede producir un daño significativo.
Si no identificamos correctamente los activos, podemos implementar controles técnicamente sofisticados alrededor de aquello que no representa el riesgo principal.
“Solo usuarios autenticados” no es una política de seguridad
Una confusión frecuente consiste en utilizar autenticación y autorización como si fueran equivalentes.
La autenticación responde:
¿Quién afirma realizar la solicitud y cómo comprobamos su identidad?
La autorización responde:
¿Puede esa identidad ejecutar esta operación sobre este recurso, en este momento y bajo estas condiciones?
La diferencia es crucial.
Un usuario legítimo puede intentar consultar el expediente de otra persona. Un colaborador autenticado puede tratar de modificar información fuera de su área. Un servicio interno puede tener credenciales válidas, pero no necesitar acceso irrestricto a todas las operaciones.
Verificar la identidad no demuestra que una acción esté permitida.
Tampoco basta con definir perfiles excesivamente amplios como “administrador”, “operador” o “usuario”. Cuando los permisos se conceden por comodidad y permanecen activos indefinidamente, la autenticación puede convertirse en la puerta de entrada a capacidades que nadie revisó con suficiente cuidado.
Una política de seguridad madura necesita expresar qué puede hacer cada actor, sobre qué recursos, bajo qué contexto y durante cuánto tiempo.
Las reglas de negocio también son controles de seguridad
La seguridad suele delegarse al equipo de infraestructura o a especialistas que operan firewalls, gateways, identidades y certificados.
Sin embargo, muchos de los riesgos más importantes solamente pueden detectarse dentro de la lógica del negocio.
Un gateway puede validar que un token sea auténtico. Difícilmente sabrá si:
- El estudiante puede consultar ese documento.
- El colaborador pertenece al campus correspondiente.
- La transacción puede modificarse después de su conciliación.
- El periodo académico continúa abierto.
- El importe corresponde al concepto autorizado.
- Una cuenta debe permanecer suspendida.
- Un trámite ya alcanzó un estado irreversible.
Estas condiciones no son detalles funcionales separados de la seguridad. Son parte de ella.
Cuando una API permite alterar el estado del negocio sin comprobar sus invariantes, el riesgo no desaparece porque la solicitud llegó mediante HTTPS y contenía un JWT válido.
La seguridad también vive en las reglas que impiden que una acción técnicamente posible se convierta en una acción indebidamente permitida.
El modelo de amenazas debe preceder al catálogo de controles
Antes de seleccionar mecanismos necesitamos pensar cómo podrían vulnerarse nuestros objetivos.
Ese ejercicio se conoce como modelado de amenazas.
No requiere comenzar con una ceremonia compleja. Una primera aproximación puede partir de preguntas concretas:
- ¿Qué ocurriría si alguien roba una credencial?
- ¿Puede un usuario cambiar el identificador de la URL y consultar otro registro?
- ¿Qué sucede si una solicitud se repite cientos de veces?
- ¿Puede modificarse un importe entre servicios?
- ¿Cómo reaccionará la plataforma si una dependencia deja de responder?
- ¿Un error devuelve información interna que facilita otro ataque?
- ¿Las bitácoras permiten reconstruir quién hizo qué?
- ¿Qué flujos atraviesan fronteras de confianza?
- ¿Qué datos compartimos con proveedores externos?
- ¿Cómo revocamos un acceso comprometido?
El valor no está únicamente en producir un documento. Está en obligarnos a observar el sistema desde la perspectiva de un posible abuso.
El modelado de amenazas transforma la seguridad de una lista genérica de controles en una conversación sobre riesgos específicos.
Solo entonces podemos decidir qué controles necesitamos y qué riesgo residual estamos dispuestos a aceptar.
No toda amenaza viene del exterior
La imagen tradicional del atacante suele ser una persona desconocida intentando entrar desde internet.
Ese escenario existe, pero es incompleto.
También debemos considerar:
- Credenciales internas comprometidas.
- Errores de configuración.
- Permisos excesivos.
- Integraciones con proveedores.
- Automatizaciones defectuosas.
- Servicios internos que se comportan de manera inesperada.
- Usuarios legítimos que utilizan una función fuera de su propósito.
- Colaboradores que conservan accesos después de cambiar de responsabilidad.
- Secretos expuestos en repositorios, registros o pipelines.
- Dependencias vulnerables.
Confiar automáticamente en una solicitud porque proviene de la red interna o de otro microservicio convierte la topología de infraestructura en una decisión de autorización.
La ubicación no sustituye la identidad. La identidad no sustituye el permiso. Y el permiso no sustituye la validación del contexto.
Cada capa responde a una pregunta diferente.
La disponibilidad también es seguridad
Cuando pensamos en seguridad solemos concentrarnos en evitar el robo o la modificación de información. Pero un servicio inaccesible también puede provocar un impacto grave.
Una API puede quedar indisponible por un ataque deliberado, por una integración defectuosa o simplemente porque un consumidor comenzó a realizar solicitudes en un volumen no previsto.
Por eso, los límites de consumo, los tiempos de espera, el control de concurrencia y los mecanismos para contener fallas forman parte de la seguridad.
El rate limiting, por ejemplo, no solamente protege contra ataques de denegación de servicio. También evita que un cliente mal configurado consuma todos los recursos y afecte a los usuarios legítimos.
La resiliencia y la seguridad se encuentran cuando preguntamos:
¿Puede una sola identidad, integración o dependencia impedir que los demás utilicen el servicio?
Una API segura no solo protege la confidencialidad y la integridad. También preserva su disponibilidad para quienes realmente necesitan usarla.
Registrar no equivale a observar
Las bitácoras son otro control que con frecuencia existe solo de manera aparente.
Podemos almacenar millones de eventos y, aun así, ser incapaces de responder preguntas básicas durante un incidente:
- ¿Quién realizó la operación?
- ¿Con qué identidad y permisos?
- ¿Desde qué aplicación?
- ¿Sobre qué recurso?
- ¿Cuál era el estado anterior?
- ¿Qué cambió?
- ¿La acción fue exitosa o rechazada?
- ¿Qué otros servicios participaron?
- ¿Existe una correlación entre solicitudes?
- ¿Se modificó o deshabilitó el registro?
Una bitácora de auditoría no es igual que un registro técnico para depurar errores.
Su propósito es proporcionar evidencia confiable sobre acciones relevantes. Para cumplirlo, debe diseñarse desde el dominio y protegerse contra alteraciones, accesos indebidos y periodos de conservación arbitrarios.
También debemos evitar el extremo contrario: registrar secretos, tokens o datos personales completos bajo la idea de que “más información siempre ayuda”.
La observabilidad necesita contexto suficiente para investigar sin convertirse en una nueva fuente de exposición.
Los secretos no dejan de ser secretos por llamarse variables de entorno
Muchas organizaciones han dejado de almacenar contraseñas directamente en el código, pero eso no significa que hayan resuelto la gestión de secretos.
Una credencial continúa en riesgo si:
- Se comparte por mensajería.
- Se reutiliza entre ambientes.
- Permanece activa durante años.
- Está disponible para más servicios de los necesarios.
- Aparece en logs o mensajes de error.
- No existe un mecanismo de rotación.
- Nadie sabe qué ocurrirá al revocarla.
- Se copia manualmente durante los despliegues.
Mover una contraseña del repositorio a una variable de entorno puede ser un paso correcto. No constituye una estrategia completa.
La gestión de secretos requiere inventario, almacenamiento seguro, distribución controlada, privilegio mínimo, rotación, revocación y trazabilidad.
De otro modo, solo habremos cambiado el lugar en el que esperamos que nadie los encuentre.
El proveedor aporta mecanismos; la organización conserva la responsabilidad
Las plataformas modernas ofrecen servicios administrados para identidad, cifrado, protección de APIs, almacenamiento de secretos y detección de amenazas.
Utilizarlos puede elevar significativamente nuestro nivel de seguridad. Sin embargo, un servicio administrado no conoce por sí mismo:
- Qué datos son sensibles para nuestro negocio.
- Qué usuarios deberían acceder a ellos.
- Qué combinación de permisos resulta peligrosa.
- Qué operaciones necesitan autorización adicional.
- Qué comportamiento representa un abuso.
- Qué impacto tendría una indisponibilidad.
- Qué evidencia debemos conservar.
El proveedor es responsable de la seguridad de determinadas capas de la plataforma. La organización continúa siendo responsable de configurar, integrar y operar esas capacidades de acuerdo con su propio riesgo.
Delegar infraestructura no significa delegar el juicio.
La seguridad debe acompañar todo el ciclo de vida
Tratar la seguridad como una revisión final produce dos problemas.
El primero es económico: corregir tarde una decisión estructural resulta más costoso que discutirla durante el diseño.
El segundo es cultural: cuando la seguridad aparece solamente al final, el equipo comienza a percibirla como un obstáculo que retrasa la liberación.
Integrarla desde el principio cambia la conversación.
Durante el diseño se identifican activos, actores y fronteras de confianza. En la implementación se aplican validaciones, controles de acceso y prácticas seguras. En las pruebas se verifican también los escenarios negativos. En el despliegue se protegen secretos y configuraciones. En la operación se observan abusos, fallas y cambios de comportamiento.
Después de un incidente, las lecciones regresan al diseño.
La seguridad no es una compuerta. Es una capacidad continua.
Una lista breve antes de construir
Antes de escribir el primer endpoint, un equipo debería poder responder al menos estas preguntas:
- ¿Qué activos protegerá la API?
- ¿Quiénes serán sus consumidores?
- ¿Qué acciones puede ejecutar cada uno?
- ¿Qué datos necesita realmente exponer?
- ¿Cuáles son las fronteras de confianza?
- ¿Qué abusos razonables debemos anticipar?
- ¿Qué operaciones requieren trazabilidad?
- ¿Cómo se revocarán los accesos?
- ¿Cómo se limitará el consumo?
- ¿Qué ocurrirá cuando una dependencia falle?
- ¿Qué información nunca debe aparecer en una respuesta o bitácora?
- ¿Quién responderá durante un incidente?
Si no tenemos respuestas, todavía no estamos listos para seleccionar tokens, roles o algoritmos.
La seguridad no es una colección de productos
Es tentador representar la seguridad como una arquitectura llena de componentes: un proveedor de identidad, un gateway, un WAF, un gestor de secretos y una plataforma de monitoreo.
Pero, como advierte Madden, no obtenemos seguridad solamente agregando cajas con las etiquetas “autenticación” o “control de acceso”.
Cada mecanismo proporciona garantías específicas y tiene límites.
La madurez consiste en entender qué riesgo reduce cada control, qué supuestos requiere y qué ocurre cuando falla. También implica reconocer que algunas decisiones no pueden comprarse como servicio: minimizar los datos, definir permisos correctos, comprender el dominio y asumir responsabilidad por la operación.
Podemos agregar seguridad al código.
Lo que no podemos agregar al final es el entendimiento que debió guiar su diseño.
Por eso, la seguridad de una API no comienza con el primer token ni termina con la última prueba de penetración.
Comienza cuando la organización decide, de manera consciente, qué promete proteger.
#APISecurity #SecureByDesign #APIGovernance #EngineeringLeadership #DevSecOps
Referencias rápidas
- Madden, N. (2020). API security in action. Manning Publications.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article