Tema 13
Una API puede tener autenticación fuerte, autorización correcta y validación estricta, pero seguir siendo insegura si el canal de comunicación permite escuchar, alterar o redirigir el tráfico. TLS y HTTPS son la base para proteger datos en tránsito, autenticar servidores y reducir la superficie de ataques de intercepción.
Las APIs transportan credenciales, tokens, datos personales, operaciones de negocio y respuestas sensibles. Si esa información viaja por un canal inseguro, un atacante puede observarla, modificarla o redirigirla aunque la lógica de aplicación sea impecable.
La seguridad en tránsito busca resolver tres problemas fundamentales:
En el ecosistema web y de APIs, esa protección se implementa principalmente mediante HTTPS sobre TLS.
HTTP transmite solicitudes y respuestas sin cifrado ni autenticación del servidor. Eso significa que cualquier actor con capacidad de observar o interferir en el canal puede inspeccionar o modificar el contenido.
HTTPS agrega una capa criptográfica mediante TLS. Gracias a ella, el cliente establece un canal cifrado con el servidor y verifica su identidad a través del certificado presentado durante el handshake.
TLS, Transport Layer Security, protege el tráfico entre cliente y servidor frente a observación y manipulación en tránsito. Cuando está bien implementado, evita que credenciales, cookies, tokens y payloads queden expuestos a sniffing o ataques Man in the Middle.
Además, ayuda a que el cliente detecte si se está conectando a un servidor falso, siempre que confíe correctamente en la cadena de certificados y no ignore errores de validación.
TLS es indispensable, pero no resuelve todos los problemas de seguridad. Es importante entender su alcance real.
| TLS protege | TLS no protege por sí solo |
|---|---|
| Tráfico frente a observación en tránsito | Errores de autorización o lógica de negocio |
| Integridad del canal | Filtraciones en responses o logs internos |
| Autenticidad del servidor | Compromiso del cliente o del backend |
| Cookies y tokens frente a sniffing de red | Mal uso de tokens o sesiones robadas por otros medios |
El certificado permite al servidor demostrar su identidad. Contiene información sobre el sujeto, la clave pública y la autoridad que lo emitió o validó. El cliente confía en ese certificado porque puede verificar una cadena de confianza hasta una autoridad reconocida.
Si esa cadena falla, el cliente debería tratar la conexión como no confiable. Ignorar advertencias de certificado es una práctica extremadamente peligrosa, tanto en navegadores como en clientes programáticos.
Estos errores pueden causar indisponibilidad, advertencias evitables o, peor, abrir la puerta a conexiones inseguras si los clientes se acostumbran a ignorar problemas.
Durante el handshake TLS, cliente y servidor acuerdan parámetros criptográficos, verifican la identidad del servidor y establecen claves de sesión para cifrar el tráfico. No es necesario memorizar todos los detalles del protocolo para operar una API segura, pero sí entender que aquí se decide la solidez del canal.
Configuraciones débiles en versiones, suites criptográficas o validación afectan esta fase y pueden degradar significativamente la seguridad real del enlace.
No todas las configuraciones TLS ofrecen el mismo nivel de protección. Versiones antiguas, suites obsoletas o parámetros débiles pueden dejar a la API expuesta a degradación de seguridad o a fallos conocidos.
Buenas prácticas generales:
HTTP Strict Transport Security, o HSTS, indica al cliente que debe conectarse siempre por HTTPS a ese dominio durante un período determinado. Esto ayuda a reducir riesgos de downgrade o intentos de forzar tráfico inseguro antes de establecer el canal cifrado.
HSTS es especialmente útil para evitar escenarios en los que un usuario o cliente cae primero en HTTP y luego es redirigido. Si el cliente ya conoce la política, salta directamente a HTTPS.
Una práctica insegura es permitir acceso inicial por HTTP y depender de una redirección posterior a HTTPS. Aunque parezca funcional, ese primer tramo puede quedar expuesto a manipulación o interceptación si el cliente aún no tiene una política estricta de transporte.
Por eso conviene:
En muchas arquitecturas, TLS no termina en la aplicación sino en un reverse proxy, load balancer o API gateway. Esto no es necesariamente un problema, pero obliga a entender muy bien dónde se descifra el tráfico y cómo se protege el tramo posterior.
Preguntas importantes:
Un error común es asumir que dentro de la red interna no hace falta proteger el tránsito. En arquitecturas distribuidas, microservicios, entornos cloud o infraestructura compartida, esa suposición suele ser demasiado optimista.
Incluso dentro del perímetro interno, puede ser necesario usar TLS o variantes de mTLS para reducir exposición entre servicios, aislar zonas de confianza y reforzar identidad de máquina a máquina.
En Mutual TLS, no solo el servidor presenta un certificado al cliente; el cliente también presenta uno al servidor. Esto permite autenticar ambas partes del canal y es especialmente útil en integraciones B2B, servicios internos críticos o entornos de alta confianza entre máquinas.
mTLS no reemplaza necesariamente otros mecanismos de identidad, pero puede reforzar mucho el control de quién está autorizado a establecer conexión a nivel de transporte.
En algunos escenarios, sobre todo clientes controlados como apps móviles o integraciones propias, puede considerarse certificate pinning para reducir dependencia exclusiva de la PKI pública. Esto busca restringir la confianza a certificados o claves esperadas.
Sin embargo, también agrega complejidad operativa. Si se implementa mal, puede romper clientes al rotar certificados o dificultar respuesta ante incidentes. No es una medida universal; debe evaluarse según capacidad de operación y tolerancia al riesgo.
Aunque TLS cifra el contenido principal, cierta metadata sigue siendo visible para infraestructura intermedia, como el destino de red y algunos aspectos del establecimiento de conexión. Además, una vez que el tráfico se descifra en el extremo, puede quedar disponible para proxies, balanceadores, logs o APMs.
Por eso la seguridad en tránsito debe complementarse con minimización de datos, logging seguro y control estricto de quién puede observar tráfico descifrado dentro de la organización.
La seguridad en tránsito no termina con instalar un certificado. También requiere operación continua:
La seguridad en tránsito es uno de los cimientos de cualquier API REST expuesta. Sin un canal cifrado y autenticado, credenciales, tokens y datos sensibles quedan vulnerables a intercepción y manipulación. TLS, HTTPS, certificados y HSTS no son detalles de infraestructura: son controles esenciales para que el resto del modelo de seguridad tenga sentido operativo real.
En el próximo tema estudiaremos CORS, cabeceras de seguridad y exposición controlada a clientes web, para analizar cómo una API debe interactuar con navegadores y orígenes cruzados sin abrir más superficie de la necesaria.