API: La nueva superficie de ataque

Las API (Interfaces de Programación de Aplicaciones) se han convertido en la capa más atacada del software moderno: 150 mil millones de los 311 mil millones de ataques web totales en 2024 se dirigieron a las API, según el informe Estado de Internet 2024 de Akamai. Las API proporcionan acceso programático directo a la lógica de la aplicación y a datos confidenciales, y proliferan más rápido que los controles de seguridad que las protegen. La acción recomendada es: tratar cada API como un punto de acceso privilegiado, aplicar TLS 1.3 y TLS mutuo para todo el tráfico, implementar la autorización a nivel de objeto en cada punto final y monitorear continuamente el comportamiento de las API para detectar anomalías que las firmas por sí solas no pueden identificar.

Respuesta rápida: ¿Por qué las API son la nueva superficie de ataque?

Las API han desplazado a las capas de aplicación tradicionales como la principal superficie de ataque por tres razones principales. Primero, proporcionan acceso programático directo a datos confidenciales y lógica de negocio sin la fricción de una capa de interfaz de usuario. Segundo, se multiplican rápidamente a medida que las organizaciones desarrollan microservicios e integran plataformas de terceros, creando cientos de puntos finales por aplicación con controles de seguridad inconsistentes. Tercero, las vulnerabilidades específicas de las API, como Broken Object Level Authorization (BOLA, OWASP API1:2023), son estructuralmente diferentes de las vulnerabilidades web tradicionales y no son detectadas por las reglas estándar de WAF ni por los escáneres de vulnerabilidades diseñados para páginas HTML. El informe de FireTail de 2024 reveló que el 57 % de las organizaciones sufrieron al menos una brecha de seguridad de API en los dos años anteriores, y entre las organizaciones afectadas, el 73 % experimentó tres o más incidentes.

¿Qué es la seguridad API?

Una API es un conjunto de reglas y protocolos que permite que las aplicaciones de software se comuniquen entre sí. Define cómo se realizan las solicitudes, cómo se intercambian los datos y cómo se estructuran las respuestas, lo que permite que los sistemas trabajen juntos de forma estandarizada. Las API impulsan prácticamente todas las tecnologías modernas: aplicaciones bancarias, portales de salud, plataformas de comercio electrónico, infraestructura en la nube y microservicios internos se comunican mediante llamadas a la API.

Las API REST (Representational State Transfer) siguen siendo el estándar dominante. Las API GraphQL (Graph Query Language) permiten a los clientes especificar con precisión los datos que necesitan y han introducido nuevas vulnerabilidades, como el abuso de introspección y el agotamiento de consultas anidadas. gRPC (Google Remote Procedure Call) utiliza búferes de protocolo y HTTP/2 para una comunicación de servicios de alto rendimiento. Las API WebSocket permiten la comunicación bidireccional persistente para aplicaciones en tiempo real. Cada tipo de API tiene un perfil de seguridad distinto que requiere controles específicos que van más allá de la seguridad general de las aplicaciones web.

La seguridad de las API se refiere al conjunto de controles que las protegen contra el acceso no autorizado, la exposición de datos, el abuso y la denegación de servicio. Dado que las API actúan como puntos de entrada directos a los sistemas backend de las aplicaciones, una seguridad deficiente de las API suele convertirse en la vía de menor resistencia para los atacantes que han agotado los controles perimetrales tradicionales.

Modelo de amenazas de API: vectores de ataque y qué vulnerabilidades explotan

Los 10 mejores sistemas de seguridad de API de OWASP (2023)	Lo que explota	Ejemplo	Control primario
API1: Autorización a nivel de objeto (BOLA) defectuosa	Faltan comprobaciones de autorización por objeto; la API verifica la autenticación, pero no si el usuario es el propietario del recurso específico.	Al cambiar /api/orders/1234 a /api/orders/1235 se devuelve el pedido de otro usuario.	Aplique la autorización a nivel de objeto en cada punto final, no solo a nivel de sesión.
API2: Autenticación defectuosa	Validación de tokens débil, falta de fecha de caducidad, aceptación de tokens de emisores incorrectos.	Se aceptan JWT con algoritmo:none; no se rechazan los tokens caducados.	Validar la firma y las reclamaciones de JWT; hacer cumplir la caducidad del token; usar tokens de corta duración.
API3: Autorización a nivel de propiedad de objeto defectuosa	La API devuelve o acepta más campos de los que el usuario está autorizado a ver o configurar.	Configuración de ataque de asignación masiva admin:true en una solicitud de actualización de usuario	Lista explícita de campos legibles y escribibles por punto final y por rol.
API4: Consumo de recursos sin restricciones	Sin limitación de velocidad; la API procesa solicitudes ilimitadas que consumen CPU, memoria o costos de descarga.	Enumeración masiva de registros de usuarios; agotamiento de consultas mediante consultas GraphQL anidadas en profundidad.	Limitación de velocidad por clave API, IP y usuario; límites de profundidad y complejidad de las consultas para GraphQL.
API5: Autorización de nivel de función defectuosa	Funciones de la API administrativa expuestas a usuarios que no son administradores.	Acceso sin privilegios de administrador a /api/admin/users para listar todos los usuarios.	API de administración separadas; aplicar control de acceso basado en roles a nivel de función.
API6: Acceso sin restricciones a flujos de negocio sensibles	API que permiten lógica empresarial de alto riesgo (creación de cuentas, pagos) sin controles de flujo.	Automatizar la creación de cuentas para crear un ejército de bots que gestionen el inventario en las cajas de las tiendas.	Limitación de velocidad basada en lógica empresarial; CAPTCHA para flujos sensibles; detección de anomalías en patrones de flujo.
API7: Falsificación de solicitudes del lado del servidor (SSRF)	La API obtiene las URL proporcionadas por el usuario, lo que permite el acceso a los servicios internos.	La API obtiene una URL que se resuelve en el servicio de metadatos interno, exponiendo las credenciales en la nube.	Lista de URL permitidas; bloquear rangos de IP privadas en la capa de aplicación.
API8: Configuración de seguridad incorrecta	Credenciales predeterminadas, mensajes de error detallados, puntos finales de depuración abiertos, falta TLS	Base de datos Elasticsearch expuesta sin autenticación; la API devuelve trazas de pila en caso de error.	Deshabilitar los modos de depuración en producción; usar mensajes de error genéricos; auditar las configuraciones.
API9: Gestión inadecuada del inventario	Los puntos finales de API no documentados o en desuso siguen activos y sin supervisión.	Punto final de API v1 heredado con autenticación más débil activo junto con v2 reforzado.	Mantener un inventario completo de API; retirar versiones obsoletas; supervisar todos los puntos finales activos.
API10: Consumo inseguro de API	Los propios sistemas de la organización confían ciegamente en los datos de las API de terceros sin validación.	La API del proveedor de pagos devuelve una URL de redireccionamiento maliciosa que se ejecuta sin validación.	Trate todas las respuestas de API de terceros como entrada no confiable; valide y sanee antes de usar.

Violaciones de API en el mundo real: ¿Qué sucedió realmente?

• Repositorios de GitHub (marzo de 2024): Aproximadamente 13 millones de secretos de API quedaron expuestos a través de repositorios públicos debido a malas prácticas de gestión de secretos. Los atacantes utilizaron estas credenciales para obtener acceso no autorizado a servicios en la nube y aplicaciones posteriores. Prevención: utilice herramientas de escaneo de secretos como GitHub Advanced Security o TruffleHog en los flujos de CI/CD; nunca incluya claves, tokens ni credenciales de API en los repositorios de código.
• Filtración de datos de la API de Dell (2024): Una API expuesta en el portal de socios de Dell permitió a los atacantes acceder a datos de 49 millones de clientes. La brecha se debió a una limitación inadecuada de las solicitudes y a la falta de detección de anomalías en el tráfico de la API. Este es un ejemplo directo de la combinación de la vulnerabilidad API4 (consumo ilimitado de recursos) y la vulnerabilidad API8 (configuración de seguridad deficiente) de OWASP.
• Abuso de la API de Microsoft Graph (mayo de 2024): Los atacantes explotaron la API de Microsoft Graph para crear canales de comunicación de malware encubiertos que afectaron a miles de organizaciones. Mediante el acceso legítimo a la API, eludieron los controles de seguridad perimetral tradicionales. Este es un ataque de tipo "Living off the Land" (LotL): actividad maliciosa que utiliza herramientas legítimas, se mimetiza con las operaciones normales y requiere detección basada en el comportamiento en lugar de controles basados ​​en firmas.
• Incidente de seguridad de API (marzo de 2025): Una base de datos Elasticsearch mal configurada, perteneciente a la empresa de pruebas de API APIsec, expuso más de tres terabytes de datos confidenciales de clientes, incluyendo resultados de escaneos de API, secretos de configuración e información de identificación personal. Un fallo de OWASP API8 (mala configuración de seguridad) en la capa de base de datos expuso datos recopilados por una herramienta de seguridad de API.
• Aplicación de té (2025): Una aplicación social anónima sufrió una brecha de seguridad que expuso 1.1 millones de mensajes privados y miles de documentos de identidad de usuarios debido a problemas de seguridad en el almacenamiento y los puntos finales de la API. Información confidencial, como números de teléfono y documentos de identidad, fue accesible a través de puntos finales de la API desprotegidos, debido a una combinación de fallos en las API 8 y 1.

Cifrado y selección de protocolos para la seguridad de las API

El cifrado protege los datos de la API tanto en tránsito como en reposo. La selección del protocolo determina si el cifrado es suficientemente robusto para los datos que se protegen:

Control	Recomendación	Qué evitar	Relevancia del cumplimiento
Cifrado del tráfico de API externa	TLS 1.3; TLS_AES_256_GCM_SHA384 o TLS_CHACHA20_POLY1305_SHA256	TLS 1.0, TLS 1.1, SSL; conjuntos de cifrado en modo CBC; intercambio de claves RSA (sin PFS)	Artículo 32 del RGPD; Norma de seguridad de HIPAA; Requisito 4 de PCI DSS
Autenticación de API interna de servicio a servicio	TLS mutuo (mTLS) con identidad basada en certificados por servicio	Claves API estáticas compartidas sin rotación; sin autenticación entre servicios internos.	Requisitos de la norma PCI DSS 8; requisitos de arquitectura de confianza cero
Secretos y credenciales de API en reposo	AES-256-GCM en un sistema de gestión de secretos o HSM dedicado; nunca en repositorios de código.	Texto plano en variables de entorno, archivos de configuración o control de versiones.	HIPAA; PCI DSS Req. 3; GDPR Art. 32
Transmisión de token	Encabezado de autorización (token de portador); nunca en las cadenas de consulta de la URL.	Tokens en los parámetros de consulta de la URL (registrados por proxies, CDN y registros de acceso del servidor)	Requisito 6 de PCI DSS; Top 10 de seguridad de API de OWASP
Datos API de larga duración (consideración de PQC)	TLS híbrido: ECDHE + ML-KEM (FIPS 203) para API que transportan datos sensibles durante más de 10 años.	Intercambio de claves solo RSA para API que transmiten registros sensibles de larga retención.	Cronograma de descontinuación de NIST IR 8547 para 2030

Autenticación, autorización y controles de acceso

Los fallos de autenticación y autorización representan la mayoría de las vulnerabilidades de API explotables en el OWASP Top 10 de 2023. Estos controles deben implementarse correctamente en cada capa:

• OAuth 2.0 y OpenID Connect: OAuth 2.0 es el estándar para la autorización delegada; OpenID Connect (OIDC) añade la verificación de identidad. Utilice el flujo de código de autorización con PKCE (Proof Key for Code Exchange) para toda la autenticación de API orientada al usuario. Las API de máquina a máquina deben utilizar el flujo de credenciales de cliente con tokens de acceso de corta duración.
• Validación de JWT (JSON Web Token): Valida la firma, el emisor (declaración iss), la audiencia (declaración aud) y la fecha de caducidad (declaración exp) en cada solicitud. Nunca aceptes JWT con el algoritmo: none. Utiliza la verificación de clave asimétrica (RS256 o ES256) en lugar de secretos simétricos compartidos (HS256) para implementaciones multiservicio.
• Autenticación multifactor (MFA): El acceso a la API iniciado por humanos (portales para desarrolladores, consolas de administración de API) debe requerir MFAClaves de acceso FIDO2 o autenticación basada en certificados A través de CertSecure Manager se proporcionan alternativas resistentes al phishing en comparación con TOTP.
• TLS mutuo (mTLS): mTLS Requiere que tanto el cliente como el servidor presenten certificados válidos durante el protocolo de enlace TLS. Para las API internas de servicio a servicio en arquitecturas de microservicios o de confianza cero, mTLS garantiza que solo los servicios autorizados puedan establecer conexiones, eliminando la autenticación basada únicamente en credenciales de la que dependen los ataques BOLA y los ataques de autenticación vulnerada.
• Grapado OCSP: habilitar Grapado OCSP En los servidores API se realizan comprobaciones de validez de certificados en tiempo real sin que los clientes tengan que consultar a la CA por separado, lo que reduce la latencia y evita el abuso de certificados revocados.
• Principio de mínimo privilegio y RBAC: Cada cliente API, usuario y cuenta de servicio recibe únicamente los permisos mínimos necesarios para su función. El control de acceso basado en roles (RBAC) o el control de acceso basado en atributos (ABAC), aplicados en la puerta de enlace API y a nivel de objeto, solucionan los fallos de autorización a nivel de función y de BOLA.

Monitoreo, registro y respuesta a incidentes

Los ataques a las API suelen tener éxito no por la ausencia de defensas, sino porque el comportamiento anómalo no se detecta hasta que se ha producido un daño significativo. La brecha de seguridad de Dell, por ejemplo, se relacionó con la falta de detección de anomalías en el tráfico de la API. Una monitorización eficaz requiere:

• Línea de base conductual y detección de anomalías: Determinar cómo es el tráfico normal de la API por punto final: volúmenes de solicitud esperados, identificadores de cliente típicos, distribución geográfica estándar y tamaños de respuesta normales. Las desviaciones, como una sola clave de API que realiza 50 000 solicitudes en una hora o respuestas consistentemente mayores que el valor de referencia, son señales de detección. Las reglas basadas en firmas detectan patrones conocidos; la detección de comportamiento detecta ataques novedosos y abusos de LotL.
• Integración SIEM: integrar SIEM Plataformas con registros de puerta de enlace API, registros de autenticación y registros de aplicaciones. La correlación SIEM identifica patrones de ataque que parecen normales en flujos de registros individuales, pero anómalos cuando se correlacionan entre diferentes fuentes.
• Registro de auditoría completo: Registre cada solicitud de API con la identidad del cliente, el punto final, el método HTTP, los parámetros de la solicitud, el código de respuesta, el tamaño de la respuesta y la marca de tiempo. Los registros deben almacenarse en un entorno protegido contra escritura, separado de la aplicación, para que un servidor comprometido no pueda alterar el registro de auditoría. La retención de registros debe cumplir con los requisitos reglamentarios aplicables (12 meses según el Requisito 10 de PCI DSS).
• Monitoreo del inventario de API: Los puntos finales no documentados y obsoletos son explotados constantemente porque no se supervisan. Mantenga un inventario completo de API y confirme que la supervisión cubre el 100 % de los puntos finales activos, incluidas las versiones antiguas que deberían retirarse.

Mejores prácticas para proteger las API: Lista de verificación para la implementación

1. Implementar TLS 1.3 en todos los puntos finales de la API; Deshabilitar TLS 1.0, 1.1 y los conjuntos de cifrado que no garantizan el secreto perfecto hacia adelante.
2. Implementar la autorización a nivel de objeto en cada punto final; No asuma que la autenticación a nivel de sesión es suficiente para prevenir BOLA.
3. Validar y desinfectar todas las entradas; Aplicar la validación del esquema JSON para las API REST, establecer límites de profundidad y complejidad de las consultas para GraphQL y rechazar las solicitudes mal formadas antes de que lleguen a la lógica de la aplicación.
4. Implementar la limitación de velocidad por clave API, usuario e IP; Aplicar retroceso exponencial en caso de intentos de autenticación fallidos repetidos.
5. Almacene todos los secretos en un sistema de gestión de secretos o HSM dedicado; Rotar las claves API según un calendario definido; escanear los repositorios en busca de credenciales confirmadas accidentalmente.
6. Utilice mTLS para la comunicación interna entre servicios; Gestionar los certificados de servicio mediante una plataforma automatizada de gestión del ciclo de vida.
7. Mantenga un inventario de API completo y actualizado; Retirar los puntos finales obsoletos; supervisar todos los puntos finales activos, incluidos los no documentados.
8. Integre herramientas DAST (Dynamic Application Security Testing), como OWASP ZAP, en los flujos de trabajo de CI/CD; Ejecute pruebas de seguridad específicas de la API antes de cada implementación.
9. Registra cada solicitud de API con todos los metadatos de la solicitud; Integración con SIEM; configuración de alertas de detección de anomalías para picos de volumen, patrones de acceso inusuales y respuestas que se desvíen significativamente del tamaño de referencia.
10. Realizar un análisis de amenazas utilizando STRIDE en cada nueva API; Asigne cada categoría de amenaza a un control específico antes de la implementación, en lugar de después de que se produzca una brecha de seguridad.

Cómo puede ayudar la consultoría de cifrado

• Servicios de asesoramiento sobre cifrado: nuestro mapa de Servicios de asesoramiento sobre cifrado Evaluamos la cobertura de cifrado de API, incluyendo la configuración de TLS, la selección de conjuntos de cifrado, la gestión de secretos y el despliegue de mTLS. Identificamos las brechas entre la postura de seguridad actual de las API y los requisitos de NIST, GDPR, HIPAA y PCI DSS, y proporcionamos una hoja de ruta priorizada para su corrección.
• Servicio de auditoría de cifrado: nuestro mapa de Servicio de auditoría de cifrado Ofrecemos un análisis exhaustivo de las prácticas criptográficas en toda su infraestructura de API, identificando secretos expuestos, algoritmos débiles, falta de implementación de TLS y deficiencias en la preparación para PQC. También evaluamos la exposición a HNDL en las API que transportan datos confidenciales de larga duración.
• Administrador de CertSecure: Administrador de CertSecure Automatiza la gestión del ciclo de vida de los certificados mTLS utilizados en la autenticación de API internas, abarcando el descubrimiento, la emisión, la renovación y la revocación en toda su malla de servicios.
• HSM como servicio: HSM como servicio Proporciona almacenamiento de hardware validado según FIPS 140-3 para las claves de firma y cifrado de la API que, de verse comprometidas, expondrían todo el tráfico de la API. El almacenamiento HSM impide la extracción de claves incluso en caso de que el servidor se vea comprometido.
• Servicios de asesoramiento de PQC: nuestro mapa de Servicios de asesoramiento de PQC Evaluar qué API se enfrentan al riesgo HNDL derivado de la amenaza cuántica, planificar implementaciones híbridas de TLS que combinen ECDHE con ML-KEM (FIPS 203) y proporcionar una hoja de ruta de migración de nueve fases alineada con el cronograma de descontinuación de 2030 de NIST IR 8547.

Limitaciones: Lo que los controles de seguridad de la API no pueden hacer por sí solos

• El cifrado no evita los fallos de autorización: TLS protege el canal, pero no impide el ataque BOLA. Un atacante que utilice un token válido para acceder a los datos de otro usuario a través de una conexión debidamente cifrada aún puede lograrlo. El cifrado y la autorización son capas de control independientes que abordan amenazas diferentes.
• Los WAF no detectan vulnerabilidades específicas de las API: Los firewalls de aplicaciones web tradicionales están diseñados para ataques a páginas HTML (XSS, inyección SQL en campos de formulario) y no cubren las vulnerabilidades principales de seguridad de la API de OWASP, como BOLA o fallos de autorización a nivel de función, que requieren lógica de capa de aplicación para su detección.
• Las pruebas estáticas no reemplazan la monitorización en tiempo de ejecución: Las pruebas DAST y de penetración detectan vulnerabilidades antes del despliegue; la detección de anomalías de comportamiento detecta ataques en producción. Ninguna sustituye a la otra. Los ataques LotL, en los que se abusa del acceso legítimo, solo pueden detectarse mediante análisis de comportamiento en tiempo de ejecución.
• Las pasarelas API no son soluciones de seguridad completas: Las pasarelas proporcionan autenticación centralizada, limitación de velocidad y registro de eventos, pero no imponen autorización a nivel de objeto (que debe implementarse en la lógica de la aplicación) ni detectan el abuso de LotL (que requiere supervisión del comportamiento).

Conclusión

Las API son la columna vertebral de los ecosistemas digitales modernos, y esa centralidad es precisamente lo que las convierte en el objetivo más atractivo para los atacantes. Con 150 mil millones de ataques a API en 2024 y el 57 % de las organizaciones sufriendo brechas de seguridad en sus API en los últimos dos años, la cuestión no es si las API de una organización serán objetivo de ataques, sino si sus controles podrán contener el daño cuando esto ocurra.

La seguridad eficaz de las API requiere controles por capas que aborden distintas categorías de amenazas: TLS 1.3 con mTLS para la seguridad del canal, OAuth 2.0 con autorización a nivel de objeto para el control de acceso, limitación de velocidad y detección de anomalías para la prevención de abusos, gestión de secretos con HSM para la protección de credenciales y monitorización continua del comportamiento para detectar los ataques que las firmas no detectan. Cada capa aborda una clase específica de amenaza; eliminar cualquiera de ellas deja una brecha que las demás no pueden cerrar.

Si desea evaluar su postura actual sobre el cifrado de API, identificar deficiencias en la autenticación y autorización, o crear los controles criptográficos que protejan los datos de la API cuando todo lo demás falle, póngase en contacto con Encryption Consulting para hablar sobre una evaluación de seguridad de API.

Preguntas frecuentes

¿Por qué las API se han convertido en la principal superficie de ataque?

Las API proporcionan acceso programático directo a la lógica de las aplicaciones y a datos confidenciales, proliferan más rápido que los controles de seguridad y contienen vulnerabilidades (BOLA, autorización a nivel de función defectuosa) que las herramientas de seguridad web estándar no detectan. De los 311 mil millones de ataques web registrados en 2024, 150 mil millones se dirigieron a las API (Akamai 2024 SOTI). FireTail constató que las brechas de seguridad en las API aumentaron un 80 % interanual en 2024.

¿Qué es BOLA (Autorización a nivel de objeto roto)?

BOLA (OWASP API1:2023) se produce cuando una API autentica a un usuario, pero no verifica que esté autorizado para acceder a un objeto específico. Un atacante modifica el ID de un objeto en la URL de la solicitud para acceder a los datos de otro usuario. La prevención requiere comprobaciones de autorización a nivel de objeto en cada punto final, no solo la autenticación a nivel de sesión.

¿Qué tipo de cifrado se requiere para la seguridad de la API?

TLS 1.3 para todo el tráfico de API externo; TLS mutuo (mTLS) para la comunicación interna entre servicios; AES-256-GCM para secretos de API y datos confidenciales en reposo almacenados en un HSM o sistema de gestión de secretos; tokens en encabezados de autorización, nunca en parámetros de URL.

¿Qué es un ataque a la API LotL (Living off the Land)?

Un ataque LotL utiliza el acceso legítimo y autorizado a la API con fines maliciosos. El atacante no explota una vulnerabilidad para obtener acceso, sino que abusa de la funcionalidad prevista de la API utilizando credenciales obtenidas legítimamente. El monitoreo de la línea base de comportamiento es el principal mecanismo de detección, ya que las herramientas basadas en firmas no pueden distinguir entre el uso legítimo y el malicioso de la misma llamada a la API.

¿Qué marcos de cumplimiento normativo requieren controles de seguridad para las API?

El artículo 32 del RGPD exige medidas técnicas para la protección de datos personales. La norma de seguridad de HIPAA exige controles de acceso, registro de auditoría y seguridad en la transmisión de información médica electrónica protegida (ePHI). Los requisitos 4, 6, 7, 8 y 10 de PCI DSS v4.0 se aplican a las API que procesan datos de titulares de tarjetas. El OWASP API Security Top 10 (2023) es la principal referencia técnica para las categorías de vulnerabilidades específicas de las API.

¿Cómo afectan los requisitos post-cuánticos a la seguridad de las API?

Las API que transportan datos sensibles de larga duración se enfrentan al riesgo cuántico HNDL (Harvest Now, Decrypt Later). El NIST finalizó ML-KEM (FIPS 203) y ML-DSA (FIPS 204) en agosto de 2024. Las organizaciones deben planificar implementaciones híbridas de TLS (ECDHE + ML-KEM) para las API de alta sensibilidad, en consonancia con la descontinuación de RSA y ECC en 2030, según lo establecido en la norma NIST IR 8547.