Las 10 vulnerabilidades de seguridad de aplicaciones web que todo equipo debería conocer

Introducción: ¿Cuándo fue la última vez que analizó la seguridad de su aplicación web más allá de simplemente hacerla funcionar? He aquí la aterradora verdad: cada campo de formulario, punto final de API, script de terceros y archivo de configuración de su aplicación podría ser un vector de ataque si no se comprueba. Las aplicaciones web modernas son más ricas y complejas que nunca, lo que significa una superficie de ataque cada vez mayor para los atacantes. De hecho, datos recientes muestran que las aplicaciones web están involucradas en casi la mitad de los incidentes de seguridad. Desde los infames Top 10 OWASP hasta los CVE recién descubiertos, las vulnerabilidades web no son una teoría abstracta, sino que están detrás de violaciones reales que sufren organizaciones de todos los tamaños.

El objetivo de este artículo es arrojar luz sobre las vulnerabilidades más críticas de las aplicaciones web, tanto desde la perspectiva del frontend como del backend. Abordaremos las más conocidas Top 10 OWASP , junto con exploits de alto perfil (como Log4Shell y otros) y errores de codificación comunes que cometen los desarrolladores en proyectos del mundo real. Para cada vulnerabilidad, explicaremos en qué consiste, daremos un ejemplo o incidente real y describiremos cómo mitigarla. También verás – destacando cómo seguridad centrada en el desarrollador de Aikido (con funciones como escaneo de código, detección de secretos, SAST y escaneo IaC) puede ayudar a detectar o prevenir estos problemas antes de que te afecten en producción.

La lista:

1. Ataques de inyección (SQL, comando, LDAP)
2. cross-site scripting
3. autenticación rota
4. control de acceso roto
5. Configuraciones de seguridad incorrectas
6. exposición de datos sensibles fuga de secretos
7. Uso de componentes con vulnerabilidades conocidas
8. Falsificación de solicitudes entre sitios (CSRF)9. Falsificación de solicitudes del lado del servidor (SSRF)
10. Deserialización insegura

¿Qué son las vulnerabilidades de las aplicaciones web?

Las vulnerabilidades de las aplicaciones web son debilidades o fallos en el diseño, la implementación o la configuración de una aplicación web que los atacantes pueden aprovechar para comprometer el sistema. Estas pueden ir desde errores de codificación, como fallos de inyección, hasta configuraciones incorrectas, como dejar abierta una consola de administración, pasando por problemas lógicos que permiten a los usuarios eludir los controles de seguridad. Algunas vulnerabilidades permiten a los atacantes robar datos o hacerse con el control de las cuentas de los usuarios; otras permiten comprometer por completo el servidor o propagar malware a sus usuarios. Muchos de los errores «clásicos» se conocen desde hace años (y se resumen en la Top 10 OWASP ), pero siguen estando muy extendidos debido a la evolución de las pilas tecnológicas y a simples errores humanos.

A continuación, analizaremos las principales vulnerabilidades de seguridad de las aplicaciones web que todo desarrollador y DevSecOps debe conocer. No se trata de una lista exhaustiva de todos los errores que existen, sino de los problemas más comunes y peligrosos que vemos hoy en día, junto con consejos para evitarlos.

Las principales vulnerabilidades de las aplicaciones web (frontend y backend)

Las siguientes vulnerabilidades se han extraído del Top 10 OWASP de exploits recientes en el mundo real. Cada una de ellas representa un riesgo grave para las aplicaciones web. Analicémoslas una por una:

1. Ataques de inyección (SQL, comando, LDAP, etc.)

Qué es: fallos de inyección cuando se envían datos no fiables a un intérprete como parte de un comando o una consulta. Los más conocidos son la inyección SQL (entrada maliciosa en consultas SQL) y la inyección de comandos del sistema operativo (entrada maliciosa ejecutada en el servidor). Cuando una aplicación incluye directamente entradas del usuario en consultas de bases de datos, comandos de shell, consultas LDAP o filtros ORM sin la validación adecuada, los atacantes pueden «inyectar» sus propios comandos. Esto puede dar lugar al robo de datos, la corrupción de datos o la toma de control completa del host. Según OWASP, la inyección es un riesgo de primer orden, y ahora incluso incluye el cross-site scripting en su clasificación.

Ejemplo: Un ejemplo muy conocido es la violación de seguridad de MOVEit Transfer en 2023. Los atacantes aprovecharon una inyección SQL de día cero (CVE-2023-34362) en la aplicación web para compartir archivos MOVEit, lo que les permitió ejecutar código remoto en el servidor. La banda de ransomware Clop utilizó este fallo para robar datos de cientos de organizaciones, lo que demuestra cómo un solo error de inyección puede derivar en una violación masiva. Este incidente demostró que SQLi no es solo un problema «anticuado», sino que sigue muy vigente y puede tener consecuencias catastróficas.

Impacto: los ataques de inyección exitosos pueden ser devastadores. Una inyección SQL puede volcar contraseñas de usuarios, registros personales o datos comerciales. La inyección de comandos del sistema operativo puede proporcionar al atacante un shell en su servidor, lo que puede comprometer toda la infraestructura. En resumen, las vulnerabilidades de inyección suelen provocar graves pérdidas de datos, el compromiso de cuentas o la ejecución remota de código, lo que las convierte en las favoritas de los atacantes.

Prevención: La clave es no mezclar nunca entradas no fiables directamente con comandos. Utilice consultas parametrizadas o sentencias preparadas para acceder a la base de datos (de modo que el intérprete SQL nunca confunda la entrada con el código). Para los comandos del sistema operativo, evite crear cadenas de comandos; utilice API seguras o incluya los valores esperados en una lista blanca. La validación de entradas y la codificación de salidas también son capas defensivas importantes. SAST análisis estático de código) basado en IA de Aikido puede ayudar a detectar patrones de inyección peligrosos en su código antes de la implementación. Por ejemplo, el escaneo de código de Aikido marcará las ocasiones en las que la entrada del usuario se concatena en sentencias SQL o se pasa a llamadas del sistema sin sanitización. Al integrar estos escáneres en su CI/CD o IDE, puede detectar y corregir automáticamente fallos de inyección. Con Aikido, ¡podría haber detectado esa consulta SQL vulnerable mucho antes que los atacantes!

2. cross-site scripting

Qué es: El Cross-Site Scripting es un tipo de inyección dirigida a los navegadores de los usuarios. Una vulnerabilidad XSS permite a un atacante inyectar scripts maliciosos del lado del cliente (normalmente JavaScript) en páginas web visitadas por otros usuarios. A diferencia del SQLi, que se dirige a su base de datos, el XSS permite al atacante manipular el contenido que ven los usuarios, lo que puede llevar al robo de tokens de sesión, la desfiguración de la interfaz de usuario o la distribución de malware. El XSS se presenta en diferentes variantes, como el XSS reflejado (el script malicioso proviene de una solicitud y se refleja en la respuesta), el XSS almacenado (el script se almacena en el servidor, por ejemplo, en un campo de comentarios de la base de datos, y se sirve a todos los espectadores) y el XSS basado en DOM (la vulnerabilidad se encuentra en el código del lado del cliente que modifica la página).

Ejemplo: Uno de los incidentes XSS más famosos fue la violación de British Airways en 2018. El grupo de hackers Magecart inyectó un script malicioso en una biblioteca JS de terceros (Feedify) utilizada en el sitio web de BA. Este script extraía los datos de las tarjetas de crédito de la página de pago y enviaba los datos a un servidor controlado por los atacantes. Los atacantes lograron robar información personal y de tarjetas de crédito de unas 380 000 transacciones antes de que se descubriera la violación. En esencia, una vulnerabilidad XSS en un componente de la cadena de suministro provocó un robo masivo de datos y costosas multas para BA. Otros ejemplos reales de XSS incluyen un error en la página web de Fortnite que podría haber expuesto millones de cuentas, y un XSS en el sitio web de eBay que los atacantes explotaron para secuestrar cuentas de vendedores de alto valor.

Impacto: XSS compromete principalmente a los usuarios, pero puede afectar indirectamente a la seguridad de su aplicación (y sin duda a su reputación). Los atacantes pueden robar cookies de sesión (para suplantar a los usuarios), realizar acciones como la víctima (como transferencias de fondos o cambios de contraseña si no hay protecciones CSRF) o mostrar formularios de phishing para engañar a los usuarios. Si la sesión de un usuario administrador es secuestrada a través de XSS, el atacante puede obtener el control total de la aplicación. Incluso los sitios no confidenciales deben preocuparse por XSS: nadie quiere que su sitio muestre solicitudes de inicio de sesión falsas o redirija a los usuarios a kits de explotación.

Prevención: La defensa contra XSS implica codificación de salida y políticas de seguridad de contenidos. Cada vez que su aplicación muestre datos proporcionados por el usuario en una página web, deberá escape adecuadamente esos datos para el contexto (HTML, JavaScript, CSS, etc.) de modo que no puedan interpretarse como código. La mayoría de los marcos web disponen de bibliotecas de plantillas o codificación; utilícelas de forma coherente (evite crear HTML a partir de cadenas sin procesar). Implemente una política de seguridad de contenidos (CSP) sólida para limitar los scripts que se pueden ejecutar en sus páginas (aunque la CSP es una segunda línea de defensa). El análisis de código de Aikido puede detectar áreas en las que se insertan entradas de usuario en la página sin la debida desinfección. Por ejemplo, si utilizas inadvertidamente innerHTML o concatenación de cadenas para inyectar datos de usuario en el DOM, el analizador estático de Aikido lo señalará. Aikido también puede identificar indicadores HTTP-only o encabezados de política de seguridad de contenido que faltan a través de su escaneo de configuración. Al detectar estos problemas de forma temprana, se evita el próximo ataque de tipo Magecart a sus usuarios. (Bonificación: la base de conocimientos integrada sobre vulnerabilidades de Aikido puede incluso sugerir prácticas de codificación seguras, como el uso de contenido del texto más de innerHTML para evitar DOM XSS).

3. autenticación rota

Qué es: autenticación rota se refiere a las debilidades en la forma en que un sitio maneja el inicio de sesión y la gestión de sesiones, como las credenciales de usuario, los ID de sesión, el restablecimiento de contraseñas y la recuperación de cuentas. Si los atacantes pueden comprometer fácilmente las contraseñas, las claves o los tokens de sesión debido a una implementación deficiente, se trata de una autenticación rota. Entre los errores más comunes se incluyen políticas de contraseñas débiles (o la ausencia limitación de velocidad el inicio de sesión, lo que permite el uso de fuerza bruta), el almacenamiento inseguro de contraseñas (por ejemplo, almacenamiento de texto sin formato o hash sin sal), el uso de ID de sesión predecibles o inseguras, la no invalidación de las sesiones al cerrar sesión y una lógica defectuosa de «recordarme» o restablecimiento de contraseña. Cualquier fallo que permita a un atacante hacerse pasar por otra persona (adivinando o robando credenciales/sesiones) o iniciar sesión sin las credenciales adecuadas entra en esta categoría. Según OWASP, estos fallos de autenticación pueden dar lugar a la apropiación de cuentas y a importantes violaciones de datos.

Ejemplo: No hay que buscar muy lejos para encontrar ejemplos: una gran parte de las violaciones de seguridad se deben al uso indebido de credenciales. De hecho, el 81 % de las violaciones relacionadas con la piratería informática en 2022 se debieron a contraseñas débiles o robadas. Un incidente concreto: a principios de 2023, Uber reveló que la cuenta de un contratista se vio comprometida porque este reutilizó una contraseña que había sido robada en una violación anterior. Los atacantes accedieron a los sistemas internos de Uber utilizando esa cuenta, lo que supuso esencialmente un fallo de autenticación (reutilización de contraseñas y falta de MFA). Otro ejemplo: una violación de seguridad en 2024 en una empresa de servicios financieros, donde la ausencia de autenticación multifactorial (MFA) permitió a los atacantes utilizar contraseñas filtradas para acceder a las cuentas, lo que afectó a millones de personas (esto se señaló en el contexto del incidente de los datos de los clientes de Snowflake: aunque la plataforma de Snowflake no fue hackeada directamente, la autenticación débil por parte de los usuarios provocó la violación). Estos casos demuestran que, incluso si el código de su aplicación es sólido, las prácticas de autenticación débiles (por parte de los usuarios o desarrolladores) pueden abrir la puerta de par en par.

Impacto: autenticación rota provocar el compromiso total de la cuenta de cualquier usuario del sistema, desde clientes habituales hasta administradores. Si un atacante obtiene las credenciales de un usuario (mediante fuerza bruta, relleno de credenciales utilizando contraseñas filtradas o aprovechando un fallo en la lógica de autenticación), puede suplantar a ese usuario y acceder a todos sus datos. Especialmente grave es si se comprometen cuentas de administrador o con privilegios: el atacante podría robar todos los datos, cambiar la configuración o adentrarse aún más en las redes internas. Incluso a menor escala, las cuentas de usuario comprometidas pueden dar lugar a fraudes, violaciones de la privacidad y pérdida de la confianza de los usuarios.

Prevención: Es imprescindible contar con defensas de autenticación robustas. Imponer requisitos de contraseñas seguras y utilizar hash (con un algoritmo fuerte como bcrypt o Argon2) además de salado para las contraseñas almacenadas; nunca almacenar contraseñas sin cifrar. Implementar la autenticación multifactorial para cuentas o acciones confidenciales; la MFA puede frustrar muchos ataques basados en contraseñas. Utilizar una gestión segura de las sesiones: hacer que los ID de sesión sean aleatorios e imposibles de adivinar, establecer su caducidad e invalidar las sesiones al cerrar sesión. Evite exponer los ID de sesión en las URL (utilice cookies con los indicadores Secure y HttpOnly). Implemente protección contra ataques de fuerza bruta (bloqueos o CAPTCHAs tras varios intentos fallidos de inicio de sesión) y supervise el relleno de credenciales.

La plataforma de Aikido puede ayudarte a detectar debilidades comunes de autenticación en tu código y configuración. Por ejemplo, el escáner de Aikido le avisará si está utilizando un método de hash de contraseñas débil (o peor aún, si almacena las contraseñas en texto plano). También puede detectar si las cookies de sesión no están marcadas como Secure/HttpOnly, o si la configuración de seguridad de su marco web (como Django o Express) está mal configurada para la gestión de sesiones. Además, la detección de secretos puede alertarte si accidentalmente codificas una clave API o una contraseña de cuenta de servicio en tu código (evitando que esos secretos se conviertan en una puerta trasera de inicio de sesión para los atacantes). Al detectar estos problemas de forma temprana, se aplica un esquema de autenticación más sólido desde el principio.

4. control de acceso roto fallos de autorización e IDOR)

Qué es: control de acceso roto actualmente el riesgo más crítico para las aplicaciones web según OWASP. Se refiere a fallos en la aplicación de autorización Es decir, las reglas sobre lo que los usuarios autenticados pueden hacer. Incluso si un usuario es quien dice ser (autenticación correcta), la aplicación debe restringirle solo a los datos y funciones permitidos. Los fallos comunes en el control de acceso incluyen no comprobar los roles/permisos de los usuarios en determinadas acciones, confiar en la aplicación por parte del cliente (que los atacantes pueden eludir) o exponer referencias a objetos internos sin verificar la propiedad. Una variante muy común es IDOR (Referencia directa a objeto inseguro), donde una aplicación utiliza identificadores proporcionados por el usuario (como números de cuenta, identificadores de documentos, etc.) para obtener datos. sin confirmando que el usuario actual tiene permiso para acceder al objeto especificado. Por ejemplo, si GET /api/pedidos/12345 devuelve el pedido n.º 12345 para cualquier usuario que lo solicite, un atacante podría simplemente cambiar el ID a 12346 y recuperar el pedido de otro usuario, un caso clásico de IDOR. Otros ejemplos incluyen la falta de comprobaciones de acceso en puntos finales de administración «ocultos» o errores de escalada de privilegios en los que un usuario normal puede convertirse en administrador modificando un parámetro o un token JWT.

Ejemplo: La prevalencia del control de acceso roto asombrosa: un estudio reveló que el 94 % de las aplicaciones probadas tenían algún tipo de debilidad en el control de acceso. En cuanto a incidentes reales, consideremos la vulnerabilidad de la API de Kia Motors (2024): los investigadores descubrieron que, con solo proporcionar el número de identificación del vehículo (VIN) o la matrícula, podían llamar a determinados puntos finales de la API de Kia/Hyundai y ejecutar de forma remota comandos del vehículo (como desbloquear las puertas), sin necesidad de ningún token de autenticación. Este fallo crítico se reducía a un fallo de control de acceso en una API: el sistema no garantizaba que la solicitud procediera de un propietario autorizado. Otro ejemplo es la brecha de MOVEit que mencionamos anteriormente: aunque se trataba principalmente de un problema de SQLi, se observó que la falta de autenticación en el punto final vulnerable permitía a los atacantes explotarlo directamente. También vemos con frecuencia errores IDOR en aplicaciones web en las que un usuario puede ver o modificar los datos de otro: por ejemplo, una vulnerabilidad de 2021 en la API de una popular plataforma de redes sociales permitió a los atacantes enumerar los ID de los perfiles de los usuarios para obtener información privada de los perfiles que debería haber estado restringida. En resumen, los controles de acceso defectuosos suelen dar lugar a una escalada de privilegios vertical (el usuario se convierte en administrador) o horizontal (el usuario A puede actuar como el usuario B).

Impacto: Cuando se rompe el control de acceso, las consecuencias van desde fugas de datos hasta la toma de control total del sistema. Un atacante podría leer datos confidenciales de otros usuarios (violando la confidencialidad) o modificar datos que no debería (violando la integridad). En casos graves, control de acceso roto permitir que un tercero obtenga privilegios de administrador, lo que supone el fin de la aplicación. Por ejemplo, un IDOR en un sitio de comercio electrónico podría permitir que alguien viera los pedidos o la información personal de otros clientes; la falta de una comprobación administrativa podría permitir que un usuario normal accediera a un /admin/eliminarUsuario punto final y borrar datos. Estas fallas conducen directamente a violaciones de confidencialidad y, a menudo, son muy fáciles de explotar por los atacantes una vez descubiertas (no se necesitan cargas sofisticadas, solo un URL o parámetro modificado).

Prevención: El mantra aquí es «denegar por defecto. Todas las solicitudes que accedan a operaciones o registros de datos confidenciales deben estar sujetas a controles de acceso por parte del servidor. Utilice marcos o middleware que centralicen la aplicación de roles/permisos. Por ejemplo, si tiene roles de usuario, asegúrese de que todas las funciones de administración verifiquen el rol del usuario en el servidor (nunca confíe únicamente en controles del lado del cliente, como ocultar los botones de administración en la interfaz de usuario). Para el acceso a nivel de objeto (como ver o editar un recurso por ID), implemente comprobaciones de propiedad, por ejemplo, confirme que el ID del pedido solicitado pertenece al usuario autenticado que realiza la solicitud. Las pruebas automatizadas pueden ayudar a verificar que el acceso no autorizado se bloquea correctamente.

Aikido te ayuda a detectar control de acceso roto varias maneras. En primer lugar, pentesting autónomo de Aikido pentesting autónomo Aikido Attack) puede sondear dinámicamente tu aplicación en ejecución en busca de estas fallas; por ejemplo, puede simular un atacante con una cuenta de usuario normal que intenta acceder a las API de administración o a los datos de otros usuarios, e informará de cualquier omisión de privilegios que haya tenido éxito. En cuanto al código, el análisis estático de Aikido puede identificar rutas o controladores con comprobaciones de autenticación faltantes (especialmente en marcos en los que las rutas deben estar anotadas con roles). Si tu código base utiliza infraestructura como código o configuración para las políticas de acceso (por ejemplo, reglas de puerta de enlace API o IAM en la nube), los escáneres de Aikido también pueden evaluarlas. Al utilizar Aikido para probar continuamente la lógica de autorización, se detectan esos errores del tipo «vaya, se me ha olvidado aplicar el inicio de sesión en ese punto final» antes de que lo hagan los atacantes. Recuerde siempre: salvo en el caso de los recursos verdaderamente públicos, todo debe requerir una autorización adecuada; Aikido puede ayudarle a verificar que cumple ese principio.

5. Configuraciones de seguridad incorrectas

Qué es: Incluso una aplicación perfectamente codificada puede verse afectada por una configuración insegura. configuración de seguridad incorrecta es una categoría amplia que abarca cualquier configuración o ajuste inseguro en la infraestructura o la pila de aplicaciones. Esto incluye cosas como: dejar credenciales predeterminadas activas en los servidores (por ejemplo, admin/admin), utilizar archivos de configuración o secretos predeterminados, dejar puntos finales sensibles (como paneles de administración de bases de datos o paneles de control en la nube) accesibles al público, no desactivar los listados de directorios en un servidor web, tener encabezados HTTP mal configurados (por ejemplo, encabezados de seguridad que faltan) u olvidar establecer los permisos adecuados en el almacenamiento en la nube. Las configuraciones incorrectas suelen deberse a que los ajustes de desarrollo/prueba no están preparados para la producción, o simplemente a errores humanos en la implementación. En entornos en la nube, una configuración incorrecta clásica es dejar un bucket S3 o un almacenamiento de blobs de Azure legible públicamente cuando contiene datos privados. Básicamente, es como si tu sistema dijera «¡Bienvenidos, atacantes, la puerta está abierta!» debido a un descuido en la configuración.

Ejemplo: Desafortunadamente, las configuraciones incorrectas causan muchas violaciones reales. Un caso llamativo de 2024: 1,3 millones de registros de pacientes quedaron expuestos en un servidor público durante dos semanas debido a una simple configuración incorrecta del servidor. No fue necesario ningún exploit: los datos se publicaron esencialmente al mundo debido a un descuido. Otro ejemplo: un incidente en Prudential Financial (2024) en el que una única configuración incorrecta en un sistema de control de acceso permitió a los atacantes acceder silenciosamente a 2,5 millones de registros de clientes. Y quién puede olvidar la violación de Capital One (2019): aunque se utilizó SSRF como mecanismo de ataque, la causa principal fue una configuración incorrecta firewall de aplicaciones web firewall de aplicaciones su entorno AWS, lo que permitió al atacante acceder a los recursos internos. En el caso de Capital One, una vez que se explotó la configuración errónea del WAF, se pudo acceder a un bucket de almacenamiento AWS S3 con datos confidenciales, lo que provocó el robo de más de 100 millones de registros de clientes. Estos ejemplos ponen de relieve que, a menudo, los «pequeños» errores de configuración (como un puerto abierto, una credencial olvidada o un control de seguridad desactivado) pueden tener consecuencias enormes.

Impacto: El impacto varía en función de lo que se haya configurado incorrectamente. En el extremo inferior, una configuración incorrecta podría «solo» filtrar información no crítica (por ejemplo, una página de error detallada que revele las versiones del software, útil para los atacantes, pero que no supone una violación en sí misma). En el extremo superior, una configuración incorrecta puede conducir directamente a un compromiso total: una interfaz de administración abierta podría permitir a los atacantes iniciar sesión (especialmente si no se cambiaron las credenciales predeterminadas), un depósito de almacenamiento en la nube abierto puede exponer millones de registros, o una configuración de seguridad desactivada podría permitir exploits triviales. Las configuraciones incorrectas se encuentran entre las principales causas de violaciones de datos en los servicios en la nube. Además, los atacantes pueden detectarlas fácilmente, ya que existen motores de búsqueda y bots que buscan continuamente elementos como paneles de control Elasticsearch/Kibana abiertos, puertos de bases de datos expuestos o depósitos públicos. En resumen, las configuraciones incorrectas pueden convertir su aplicación segura en un «patio de recreo para hackers» si no se tiene cuidado.
‍
Prevención: la diligencia y la automatización son fundamentales. Cambie siempre las contraseñas y claves predeterminadas (nada debe funcionar con «admin/admin» o valores predeterminados similares). Refuerce las configuraciones de su servidor y marco de trabajo: por ejemplo, desactive los modos de depuración y las aplicaciones de muestra en producción, asegúrese de que la exploración de directorios esté desactivada y aplique los encabezados de seguridad recomendados (política de seguridad de contenido, X-Frame-Options, etc.). Utilice el principio del mínimo privilegio para los recursos en la nube: si un servicio o un bucket no necesita acceso público, bloquéelo (y para aquellos que deban ser públicos, asegúrese de que solo expongan lo que se pretende). Revise periódicamente su infraestructura como código o la configuración de su entorno en función de los parámetros de seguridad.

escaneo IaC la auditoría de configuración de Aikido pueden ser de gran ayuda en este caso. Si utiliza Terraform, CloudFormation, Kubernetes YAML o similares, Aikido puede escanearlos en busca de configuraciones inseguras (como grupos de seguridad abiertos, buckets S3 públicos o configuraciones de cifrado que faltan). También puede comprobar si hay configuraciones incorrectas en su entorno de nube en ejecución. En el caso de los servidores web y las aplicaciones, los escáneres de Aikido señalarán los encabezados de seguridad que faltan o los mensajes de error demasiado detallados. Además, la protección en tiempo de ejecución de Aikido protección en tiempo de ejecución pueden supervisar el uso anormal que podría indicar que alguien está aprovechando una configuración incorrecta. La conclusión es que las comprobaciones de configuración deben formar parte de su proceso: Aikido puede automatizarlo, detectando los errores del tipo «vaya, dejé ese bucket público» antes de la implementación. Y esté siempre atento a los nuevos parches y actualizaciones; a veces, las configuraciones incorrectas se deben al uso de software obsoleto con debilidades predeterminadas conocidas.

6. exposición de datos sensibles filtración de secretos

Qué es: esta categoría abarca los fallos a la hora de proteger adecuadamente la información confidencial, tanto los datos de los usuarios como las claves secretas.exposición de datos sensibles(también denominada fallos criptográficos) significa que una aplicación no protege adecuadamente los datos en tránsito o en reposo. Algunos ejemplos son no utilizar HTTPS para comunicaciones confidenciales, utilizar un cifrado débil o no utilizarlo para los datos almacenados (como hash sin sal para contraseñas o datos personales en texto plano en una copia de seguridad de la base de datos) o exponer accidentalmente datos a través de la depuración o los registros. Estrechamente relacionado con esto está la filtración de secretos, que se produce cuando los desarrolladores exponen inadvertidamente información si no se tiene cuidado.

Prevención: la diligencia y la automatización son fundamentales. Cambie siempre las contraseñas y claves predeterminadas (nada debe ejecutarse con «admin/admin» o valores predeterminados similares). Refuerce las configuraciones de su servidor y marco de trabajo: por ejemplo, desactive los modos de depuración y las aplicaciones de muestra en producción, asegúrese de que la exploración de directorios esté desactivada y aplique los encabezados de seguridad recomendados (política de seguridad de contenido, X-Frame-Options, etc.). Utilice el principio del mínimo privilegio para los recursos en la nube: si un servicio o un bucket no necesita acceso público, bloquéelo (y para aquellos que deban ser públicos, asegúrese de que solo expongan lo que se pretende). Revise periódicamente su infraestructura como código o la configuración de su entorno en función de los parámetros de seguridad.

escaneo IaC la auditoría de configuración de Aikido pueden ser de gran ayuda en este caso. Si utiliza Terraform, CloudFormation, Kubernetes YAML o similares, Aikido puede escanearlos en busca de configuraciones inseguras (como grupos de seguridad abiertos, buckets S3 públicos o configuraciones de cifrado que faltan). También puede comprobar si hay configuraciones incorrectas en su entorno de nube en ejecución. En el caso de los servidores web y las aplicaciones, los escáneres de Aikido señalarán los encabezados de seguridad que faltan o los mensajes de error demasiado detallados. Además, la protección en tiempo de ejecución de Aikido protección en tiempo de ejecución pueden supervisar el uso anormal que podría indicar que alguien está aprovechando una configuración incorrecta. La conclusión es que las comprobaciones de configuración deben formar parte de su proceso: Aikido puede automatizarlo, detectando los errores del tipo «vaya, dejé ese bucket público» antes de la implementación. Y esté siempre atento a los nuevos parches y actualizaciones; a veces, las configuraciones incorrectas se deben al uso de software obsoleto con debilidades predeterminadas conocidas.

6. exposición de datos sensibles filtración de secretos

Qué es: esta categoría abarca los fallos a la hora de proteger adecuadamente la información confidencial, tanto los datos de los usuarios como las claves secretas.exposición de datos sensibles(también denominada fallos criptográficos) significa que una aplicación no protege adecuadamente los datos en tránsito o en reposo. Algunos ejemplos son no utilizar HTTPS para las comunicaciones confidenciales, utilizar un cifrado débil o no utilizarlo para los datos almacenados (como hash sin sal para las contraseñas o datos personales en texto plano en una copia de seguridad de la base de datos) o exponer accidentalmente los datos a través de la depuración o los registros. Estrechamente relacionado con esto está la filtración de secretos, que se produce cuando los desarrolladores exponen inadvertidamente secretos como claves API, contraseñas de bases de datos, credenciales o tokens, ya sea codificándolos en el código, dejándolos en archivos de configuración enviados a repositorios o almacenándolos en código del lado del cliente. Cada año, los desarrolladores filtran una cantidad asombrosa de secretos (a menudo en GitHub público). En resumen, si tu aplicación no cifra adecuadamente lo que debe cifrarse, o si eres descuidado con la información confidencial y las claves, estás invitando a los atacantes a obtener esos datos sin mucho esfuerzo.

Ejemplo: Una de las caras de este problema son los datos sin cifrar. Un ejemplo sencillo pero ilustrativo: hace muchos años, los sitios web a veces aceptaban credenciales de inicio de sesión a través de HTTP sin cifrar; esos días han quedado atrás en gran medida, pero incluso ahora se producen errores. En 2023, se descubrió que una importante integración de API transmitía datos personales de salud sin el cifrado adecuado (debido a una cadena de certificados TLS mal configurada), exponiendo información privada en la red. Otro ejemplo: si un archivo de copia de seguridad de una base de datos se almacena en un depósito en la nube no seguro (debido a una configuración incorrecta), todos los datos personales que contiene podrían quedar expuestos. Esto le ocurrió a una aerolínea en 2022, que filtró cientos de miles de registros de clientes porque la copia de seguridad no estaba cifrada ni controlada por acceso.

En lo que respecta a los secretos, el problema es endémico. Solo en 2024, los investigadores detectaron casi 23,8 millones de nuevos secretos codificados en commits públicos de GitHub, lo que supone un aumento del 25 % con respecto al año anterior. Esta «proliferación de secretos» ha dado lugar a violaciones reales. Por ejemplo, en 2023, un atacante filtró todo el código fuente del New York Times desde un repositorio privado, supuestamente aprovechando credenciales filtradas. En otro caso, una empresa de inteligencia empresarial (Sisense) sufrió la filtración de una credencial interna en un foro público, que los atacantes utilizaron para acceder a datos confidenciales de los clientes. Más cerca de casa para los desarrolladores: ¿cuántas veces hemos oído hablar de una clave secreta de AWS enviada accidentalmente a GitHub, solo para que los mineros de criptomonedas o, peor aún, la utilizaran en cuestión de minutos? Estos ejemplos muestran que no proteger los datos con cifrado y no mantener los secretos en secreto puede conducir directamente a violaciones de datos y accesos no autorizados.

Impacto: Si se exponen datos confidenciales de los usuarios (información personal, datos financieros, historiales médicos, etc.), el impacto suele recaer tanto en los usuarios (violaciones de la privacidad, riesgo de robo de identidad) como en la empresa (sanciones reglamentarias, daño a la reputación). Por ejemplo, la exposición de historiales médicos puede dar lugar a multas y demandas en virtud de la HIPAA. La exposición de contraseñas o números de tarjetas de crédito conduce, obviamente, al fraude. Por otra parte, la filtración de secretos (como claves API o tokens) puede ser un billete dorado para los atacantes: por ejemplo, la filtración de una contraseña de base de datos podría permitir a un atacante conectarse y vaciar toda la base de datos; la filtración de una clave API en la nube podría permitirles poner en marcha servidores (a su costa) o acceder a datos confidenciales en la nube. Una credencial de administrador filtrada puede, en ocasiones, comprometer toda una aplicación o incluso un conjunto de sistemas. No es de extrañar que el informe de IBM sobre el coste de las violaciones de datos concluya sistemáticamente que las violaciones que implican credenciales comprometidas y datos confidenciales se encuentran entre las más costosas (tanto en dólares como en pérdida de confianza).

Prevención: Hay dos aspectos que tener en cuenta: proteger los datos confidenciales y gestionar adecuadamente los secretos. Para los datos confidenciales de usuarios/empresas, utilice siempre HTTPS (aplique TLS para todo el tráfico y utilice protocolos/configuraciones modernos). Nunca transmita información confidencial como contraseñas o tokens en texto plano, ni siquiera en comunicaciones internas. Cuando los datos estén en reposo, cifre los campos de datos críticos (muchas bases de datos y servicios de almacenamiento en la nube ofrecen cifrado en reposo; utilícelo y considere el cifrado a nivel de aplicación para los campos extremadamente confidenciales). Evite la exposición excesiva de datos: no almacene innecesariamente datos que no necesite y elimine los datos confidenciales cuando ya no sean necesarios. En cuanto a la gestión de secretos: nunca codifique secretos en el código o la configuración que se envía al control de código fuente. Utilice variables de entorno, servicios de gestión de secretos (como HashiCorp Vault o almacenes de secretos en la nube) o, como mínimo, almacene los secretos en archivos de configuración seguros que no se encuentren en el repositorio. Si debe confirmar alguna configuración, utilice herramientas para buscar secretos antes de enviarla. Rote las claves con regularidad para que, si se produce alguna fuga, solo sea válida durante un breve periodo de tiempo.

La plataforma de seguridad de Aikido cuenta con potentes funciones que ayudan en ambos frentes. Su detección de secretos analizará su código y configuración en busca de claves API, contraseñas, certificados privados y otras credenciales. Por ejemplo, si alguien deja accidentalmente una clave AWS o una cadena de conexión de base de datos en un archivo confirmado, Aikido lo marcará inmediatamente, lo que podría evitarle el robo de su cuenta AWS. Aikido puede incluso supervisar sus repositorios de forma continua para detectar fugas de secretos en tiempo real. En cuanto a la protección de datos, el escaneo de Aikido puede identificar el uso de criptografía débil (como el uso de funciones hash o algoritmos de cifrado obsoletos). También puede verificar ciertos controles de cumplimiento (por ejemplo, asegurarse de que tienes TLS habilitado en todos los puntos finales mediante el escaneo de la infraestructura como código o las definiciones de API). Al integrar Aikido, obtienes un vigilante automatizado que grita «¡Eh, eso es una clave API, elimínala!» antes de que llegue a producción. Y si tu organización tiene muchos repositorios privados o equipos de desarrolladores, este tipo de escaneo automatizado de secretos es esencial, como lo demuestra el número cada vez mayor de secretos que se encuentran en el código cada año.

7. Uso de componentes con vulnerabilidades conocidas (riesgos de la cadena de suministro)

Qué es: Las aplicaciones web modernas se basan en innumerables componentes de terceros: marcos, bibliotecas, paquetes, imágenes de contenedores y servicios. El uso de componentes con vulnerabilidades conocidas significa que su aplicación incluye una dependencia (o se ejecuta en un servidor) que tiene una falla de seguridad conocida públicamente y que usted no ha parcheado ni actualizado. Se trata, en esencia, del problema de la «cadena de suministro»: una vulnerabilidad en una biblioteca que usted utiliza puede comprometer su aplicación, incluso si su propio código es perfecto. Los ejemplos abundan: una versión vulnerable de un marco web, una biblioteca OpenSSL obsoleta, una herramienta de depuración con fugas, etc. Los atacantes buscan activamente aplicaciones que utilicen versiones vulnerables específicas de software para explotarlas. Top 10 OWASP hecho hincapié en este riesgo (antes «Uso de componentes con vulnerabilidades conocidas», ahora incluido en una categoría más amplia en 2021), y la industria ha aprendido duras lecciones de incidentes como Log4Shell, en el que un único fallo en una biblioteca tuvo un efecto dominó a nivel mundial.

Ejemplo: El ejemplo más claro es, sin duda, Log4Shell (CVE-2021-44228). Se trataba de una vulnerabilidad crítica de RCE en la popular biblioteca de registro Log4j (muy utilizada en aplicaciones Java). Cuando se reveló en diciembre de 2021, hizo saltar las alarmas en todas partes, ya que miles de aplicaciones eran indirectamente vulnerables, si incluían una determinada versión de Log4j. Los atacantes comenzaron rápidamente a explotarla, lo que provocó incidentes en muchas empresas. Como se indica en un informe, «la vulnerabilidad de Log4j demostró cómo un único componente ampliamente utilizado puede crear una exposición en toda la organización». Otro ejemplo: Apache Struts 2 tenía un fallo RCE conocido (CVE-2017-5638) que provocó la famosa brecha de Equifax en 2017: Equifax no había actualizado el marco y los atacantes lo explotaron para robar datos de 147 millones de personas. Más recientemente, en 2022-2023, vimos Spring4Shell (CVE-2022-22965), una vulnerabilidad de Spring Framework que se hacía eco de Log4Shell (aunque menos grave), y varias vulnerabilidades de paquetes npm/PyPI que permitían a los atacantes ejecutar código o robar datos si se utilizaban esos paquetes. Ni siquiera las bibliotecas front-end se libran: por ejemplo, una vulnerabilidad en la biblioteca DOMPurify en 2021 podría socavar protección XSS no se actualiza. Todo esto ilustra que las CVE conocidas en su pila son bombas de relojería.

Impacto: El impacto depende totalmente de la vulnerabilidad específica del componente, pero puede ser muy grave: ejecución remota de código, fuga de datos, omisión de autenticación, etc. El problema es que estas vulnerabilidades son de dominio público y, a menudo, el código de explotación está fácilmente disponible, por lo que los atacantes pueden automatizar los escaneos para encontrar cualquier servidor que no haya sido parcheado. Un solo componente sin parchear puede provocar un compromiso masivo si es susceptible de ser infectado por un gusano (como ocurrió con las vulnerabilidades MS Exchange ProxyShell/ProxyLogon de 2021, que no eran exactamente «aplicaciones web», pero sí un concepto similar de vulnerabilidades conocidas explotadas de forma masiva). En el caso de su aplicación, el uso de un componente vulnerable podría significar que un atacante no necesita encontrar un error en su código, sino que simplemente explota la biblioteca. El resultado puede ser el mismo que en otras categorías: violación de datos, apropiación del servidor, etc., pero es especialmente frustrante porque es posible que haya una solución disponible y simplemente no se haya aplicado.

Prevención: Esto se reduce a Gestión de dependencias y disciplina de aplicación de parches. Mantenga un inventario de todos los componentes (incluidas sus versiones) utilizados en su aplicación; esto se denomina a menudo lista de materiales de software SBOM). Suscríbase a fuentes de vulnerabilidades o utilice herramientas automatizadas para que le avisen cuando una biblioteca que utiliza tenga un CVE conocido. Muchos gestores de paquetes tienen comandos de auditoría (por ejemplo, Auditoría de npm, auditoría de pip) para identificar vulnerabilidades conocidas en su árbol de dependencias. Mantenga sus dependencias actualizadas: actualice rápidamente a las versiones parcheadas. Siempre que sea posible, utilice herramientas para aplicar parches virtuales o soluciones alternativas si no puede actualizar inmediatamente. Para componentes como su sistema operativo, servidor web o servidor de bases de datos, aplique actualizaciones de seguridad con regularidad. Tenga también cuidado con paquetes maliciosos En el ecosistema de código abierto, en ocasiones los atacantes publican una biblioteca comprometida (o secuestran una cuenta de administrador) para que la próxima vez que npm install, es posible que esté descargando una actualización con puerta trasera. Utilizar fuentes fiables y bloquear las versiones de las dependencias (además de verificar la integridad mediante sumas de comprobación/firmas) puede ayudar a mitigar ese riesgo.

Aikido facilita enormemente la gestión de este riesgo gracias a sus análisis de dependencias análisis de composición de software SCA) y análisis de dependencias . El escáner de dependencias (SCA) de Aikido detecta automáticamente las bibliotecas de código abierto y las versiones que utiliza su código, las compara con bases de datos de vulnerabilidades y le avisa de cualquier CVE conocido. Por ejemplo, si su proyecto está utilizando, por ejemplo, Log4j 2.14.0 (que es vulnerable a Log4Shell), Aikido lo marcaría con detalles sobre el CVE e incluso sugeriría la versión corregida a la que debería actualizar. Puede hacerlo directamente en su IDE o canalización de CI. Y lo que es aún mejor, Aikido proporciona corrección automática con IA : en muchos casos, puede abrir automáticamente una solicitud de extracción para actualizar una dependencia a una versión más segura o aplicar el parche necesario. La plataforma también puede escanear imágenes de contenedores en busca de componentes obsoletos (asegurando que sus imágenes base y paquetes de SO estén actualizados). Al integrar Aikido, básicamente externalizas la tediosa tarea de rastrear CVE a un sistema automatizado que nunca duerme. Esto significa una corrección más rápida, algo fundamental cuando los exploits suelen estar en circulación días u horas después de que se anuncie una vulnerabilidad. En resumen: mantén todo actualizado y utiliza herramientas como Aikido SCA para adelantarte a los atacantes en el frente de los componentes.

8. Falsificación de solicitudes entre sitios (CSRF)

Qué es: La falsificación de solicitudes entre sitios (Cross-Site Request Forgery) es un ataque en el que un sitio web malicioso engaña al navegador de un usuario para que realice solicitudes no deseadas a su aplicación web. Aprovecha el hecho de que los navegadores incluyen automáticamente credenciales (como cookies de sesión) con las solicitudes. Si un usuario ha iniciado sesión en su sitio y luego visita un sitio malicioso, ese sitio malicioso podría, por ejemplo, cargar una imagen o un formulario oculto que envíe una solicitud a su sitio (el objetivo), y el navegador incluirá la cookie de sesión del usuario. Sin una defensa adecuada, su servidor pensará que el usuario ha realizado esa solicitud de forma legítima y la ejecutará. En esencia, CSRF «secuestra» la sesión autenticada de un usuario para realizar una acción que el usuario no pretendía. Ejemplo clásico: un usuario ha iniciado sesión en su banco. Visita la página de un atacante que tiene un código oculto que envía una solicitud de transferencia de fondos al sitio del banco; el banco ve una cookie de sesión válida y procesa la transferencia. El CSRF no roba datos directamente, sino que engaña al navegador de la víctima para que se convierta en cómplice del atacante. Muchos marcos modernos tienen protecciones CSRF integradas (normalmente a través de tokens), y los navegadores modernos han añadido atributos de cookies SameSite para mitigar el CSRF, pero está lejos de haber sido erradicado. En 2025, el CSRF «no ha desaparecido, solo ha cambiado», especialmente con las aplicaciones de una sola página y las API que utilizan cookies para la autenticación, donde los desarrolladores pueden olvidarse de implementar las protecciones habituales.

Ejemplo: Un caso real: Reddit (2023) tenía una vulnerabilidad CSRF en una página de configuración que permitía a los atacantes cambiar silenciosamente las preferencias de un usuario e incluso vincular la cuenta de la víctima a una cuenta de spam. Aunque cambiar las preferencias de notificación no es tan grave como transferir dinero, demuestra que CSRF estaba presente en la funcionalidad de un sitio web importante. Otro ejemplo destacado es el de las aplicaciones de monederos de criptomonedas: los atacantes han utilizado CSRF para cambiar las direcciones de pago predeterminadas o iniciar pequeñas transacciones aprovechando la interfaz web del monedero, lo que les ha permitido drenar fondos sin que el usuario se diera cuenta. Históricamente, también ha habido ataques CSRF más devastadores: Gmail sufrió un ataque CSRF en 2007 que permitió a los atacantes cambiar las direcciones de reenvío de correo electrónico de los usuarios (espiando los correos electrónicos), y en 2005 se produjo el famoso gusano Samy en MySpace, que en realidad era un CSRF autopropagable (combinado con XSS) que hizo que el perfil de Samy Kamkar acumulara un millón de «amigos». Estos ejemplos van desde travesuras hasta infracciones importantes, pero todos subrayan la idea: si no se dispone de protecciones CSRF, un atacante puede hacer que los usuarios realicen acciones que no pretendían.

Impacto: La gravedad del CSRF depende de las acciones que sean vulnerables. Si solo es posible realizar algunos cambios menores en las preferencias (como en el ejemplo de Reddit), el impacto es limitado (molesto, pero no catastrófico). Pero si acciones críticas como transferencias de dinero, cambios de contraseña o eliminaciones de cuentas son vulnerables, entonces el CSRF es un problema grave. Pensemos en un CSRF que cambia la contraseña de un usuario conectado por una conocida por el atacante: eso supone la apropiación total de la cuenta. O un CSRF en una aplicación bancaria basada en la web que emite un pago: eso es un robo financiero directo. En un contexto corporativo, un CSRF que desencadena algún cambio de estado (como cambiar una configuración de control de acceso o inyectar datos maliciosos) podría ser un trampolín hacia un compromiso más profundo. La naturaleza silenciosa del CSRF (sin malware en el equipo del usuario, sin signos externos inmediatos) significa que estos ataques pueden pasar desapercibidos hasta que es demasiado tarde.

Prevención: La buena noticia es que el CSRF se conoce bien y existen defensas estándar:

• Tokens CSRF: Implementa tokens anti-CSRF para solicitudes que cambian el estado. El servidor genera un token aleatorio, lo establece en la sesión del usuario (o como una cookie) y también lo inyecta en formularios o API (como un campo oculto o un encabezado). Cuando llega una solicitud, el servidor espera el token y lo verifica. La solicitud falsificada de un atacante no tendrá el token correcto, por lo que será rechazada.
• Atributo SameSite de las cookies: Configure sus cookies de sesión con SameSite=Lax o Estricto. Esto ayuda a evitar que el navegador incluya cookies en solicitudes entre sitios (aunque Relajado todavía permite algunas solicitudes GET, que idealmente no deberían tener efectos secundarios). Muchos marcos ahora establecen por defecto las cookies de sesión en SameSite=Lax. Solo ten cuidado si tu aplicación necesita legítimamente solicitudes entre sitios (por ejemplo, integraciones de terceros): es posible que necesites excepciones, pero, si es así, aíslalas.
• Asegúrate de que las acciones que cambian el estado usen los verbos HTTP correctos (por ejemplo, usa POST/PUT/DELETE, no GET, para las acciones). Los navegadores no enviarán credenciales en POST entre sitios si SameSite es Lax o Strict, y es más difícil para un atacante hacer un POST oculto que un GET.
• Comprueba los encabezados Origin/Referer: como medida adicional, verificar que las solicitudes provienen del dominio esperado puede detectar intentos de cross-site en algunos casos (aunque no es infalible).
• Seguridad del marco: utilice el middleware de protección CSRF integrado en su marco; casi todos los marcos modernos lo tienen.
• No lo desactives durante el desarrollo (los desarrolladores a veces desactivan las comprobaciones CSRF para probar las API y luego se olvidan de volver a activarlas).

Aikido puede ayudarte a garantizar que tu aplicación no sea vulnerable a CSRF sin que tú lo sepas. Por un lado, escaneo dinámico del aikido escaneo dinámico DAST) Puede simular CSRF intentando realizar acciones que cambian el estado desde un contexto externo y comprobando si tiene éxito. Informará de cualquier acción que carezca de la protección CSRF adecuada. En cuanto al código, el análisis estático de Aikido (con su comprensión de los marcos) puede identificar rutas que modifican datos pero que no cuentan con verificación de tokens CSRF. (De hecho, herramientas como Ghost Security, una AppSec similar, anuncian específicamente que encuentran «puntos finales que mutan el estado pero carecen de tokens CSRF», y Aikido ofrece capacidades comparables). Aikido también puede detectar configuraciones incorrectas. SameSite atributos inspeccionando los encabezados Set-Cookie en sus respuestas o configuraciones de seguridad. Al utilizar Aikido para probar sus formularios y puntos finales de API, se le avisará si alguna ruta crítica carece de defensas CSRF, para que pueda solucionarlo (normalmente añadiendo las comprobaciones de token o encabezado adecuadas). Con estas medidas, puede eliminar eficazmente el CSRF, asegurándose de que su aplicación solo honra las solicitudes que realmente provienen de tu sitio y tus usuarios.

9. Falsificación de solicitudes del lado del servidor (SSRF)

Qué es: SSRF es una incorporación reciente al Top 10 OWASP entró en el Top 10 en la edición de 2021) y por una buena razón. Falsificación de solicitudes del lado del servidor Se produce cuando una aplicación toma una URL o la ubicación de un recurso de una fuente no fiable (como la entrada del usuario) y el código del lado del servidor busca esa URL sin la validación adecuada. Básicamente, un atacante engaña a tu servidor para que envíe una solicitud en su nombre. Esto puede utilizarse de forma indebida para que el servidor realice solicitudes a recursos internos a los que el atacante no puede acceder directamente, o a direcciones externas con las credenciales del servidor. Un escenario clásico es una aplicación web con una función como «obtener el contenido de esta URL» (para previsualizar o importar datos): un atacante proporciona una URL como http://localhost/admin o una URL de metadatos de AWS (http://169.254.169.254) para recuperar información interna confidencial a través de su servidor. SSRF también puede permitir el escaneo de puertos de su red interna a través de su servidor, o incluso la explotación de servicios internos. En entornos de nube, SSRF es particularmente peligroso porque las instancias de nube a menudo tienen acceso a puntos finales de metadatos que proporcionan credenciales. La violación de Capital One en 2019 fue un excelente ejemplo del uso de SSRF en la vida real (combinado con una configuración incorrecta).

Ejemplo: La violación de Capital One: una antigua ingeniera de AWS explotó una vulnerabilidad SSRF en un WAF ( firewall de aplicaciones web firewall de aplicaciones) mal configurado que Capital One tenía en funcionamiento. Mediante la creación de solicitudes desde una aplicación web accesible desde el exterior, pudo consultar el servicio de metadatos de AWS del servidor, que devolvió tokens de acceso de AWS. Con esos tokens, accedió a datos confidenciales (buckets S3 con información de clientes), lo que provocó el robo de más de 100 millones de registros. En resumen, SSRF fue el punto de entrada inicial que eludió las barreras de la red externa aprovechando los privilegios del propio servidor. Otro ejemplo: en 2022, los investigadores de seguridad descubrieron que un SSRF en una popular herramienta de DevOps les permitía acceder a puntos finales de API internos que de otro modo no estarían expuestos, lo que potencialmente permitía acciones administrativas. También hemos visto errores SSRF en funciones de procesamiento de imágenes o generación de PDF (donde el servidor obtiene una URL de la entrada) que los atacantes convirtieron en escáneres de puertos o utilizaron para atacar consolas de administración de bases de datos internas. Otro caso más: algunos servicios en la nube tenían SSRF en sus webhooks que permitían a los atacantes activar solicitudes a puntos finales HTTP internos, obteniendo acceso a cosas como Redis o paneles de control internos.

Impacto: A primera vista, el SSRF consiste en realizar solicitudes, lo que puede parecer limitado. Sin embargo, puede tener un impacto crítico:

• Acceso a la red interna: si su servidor puede comunicarse con hosts internos (por ejemplo, en la misma VPC o centro de datos), un SSRF podría comunicarse con servicios internos que no están expuestos públicamente. Esto podría dar lugar a la lectura de datos confidenciales (como contactar con una API HTTP interna que devuelve información de clientes) o incluso a la emisión de comandos privilegiados si una interfaz de administración interna carece de autenticación (ya que se supone que solo las llamadas internas pueden acceder a ella).
• Fuga de metadatos en la nube: en los proveedores de servicios en la nube (AWS, GCP, Azure), SSRF se utiliza a menudo para obtener credenciales del servicio de metadatos de la instancia. Estas credenciales podrían permitir un mayor compromiso de los recursos en la nube (como en Capital One).
• Elusión de restricciones basadas en IP: si restringe alguna funcionalidad, por ejemplo, a las solicitudes procedentes de «localhost» o de determinadas direcciones IP, un SSRF podría eludir esa restricción realizando la solicitud desde el propio servidor local.
• Potencial de propagación: en algunos casos, SSRF puede ser un punto de inflexión para futuros exploits; por ejemplo, SSRF a un servicio interno que tiene un RCE conocido podría dar lugar a la ejecución remota de código en la red interna.
  Según la nota de OWASP, los problemas de SSRF están aumentando en las aplicaciones modernas debido a la complejidad de los microservicios y la nube, y pueden ser bastante graves.

Prevención: Prevenir la SSRF significa principalmente Validar y desinfectar cualquier URL proporcionada por el usuario o solicitud de recursos remotos.Si su aplicación necesita recuperar una URL proporcionada por un usuario (o una dirección), implemente una lista de permisos estricta: por ejemplo, solo permita URL de un conjunto de dominios en los que confíe (y aplique esa restricción mediante búsqueda DNS, etc., para evitar trucos). Nunca permita que las entradas sin procesar de los usuarios controlen directamente el destino de las recuperaciones del lado del servidor. También puede implementar protecciones a nivel de red: por ejemplo, desactivar la capacidad de su servidor para acceder a direcciones internas si no es necesario. Algunos proveedores de nube le permiten desactivar o restringir el acceso al servicio de metadatos (AWS tiene IMDSv2, que mitiga las solicitudes GET simples). Además, el código debe comprobar el esquema de la URL: no permitir file:// URI u otros esquemas locales, y potencialmente deshabilitar literales IP o direcciones locales de enlace. Utilizar bibliotecas o parches que realicen protección SSRF si están disponibles (por ejemplo, algunas bibliotecas de clientes HTTP permiten restringir los hosts con los que se puede contactar). Básicamente, tratar las URL proporcionadas externamente como entradas peligrosas, porque lo son.

Las herramientas de análisis de Aikido pueden ayudar a identificar riesgos SSRF en su código. Por ejemplo, el análisis estático de Aikido puede detectar el uso de funciones o bibliotecas que realizan solicitudes HTTP (como solicitudes.obtener() en Python, HttpClient en Java, etc.) donde la URL se deriva de la entrada del usuario. A continuación, puede marcarlo como un posible SSRF si no hay filtrado. Aikido también puede detectar si su código intenta obtener elementos de URL sin validación, y puede sugerir añadir comprobaciones de listas de permitidos. En el lado dinámico, Las herramientas DAST pentest de Aikido puede intentar cargas útiles SSRF comunes (como proporcionar http://169.254.169.254 como entrada para cualquier funcionalidad de obtención de URL) para ver si pueden engañar al servidor para que responda con contenido interno. Si se encuentra un vector SSRF, Aikido lo notificará junto con las pruebas. Con esta información, podrá implementar la validación adecuada o restringir el acceso a la red. Las funciones de análisis en la nube de Aikido también pueden advertirle si sus instancias tienen una configuración de red demasiado permisiva (por ejemplo, si su servidor web puede salir a Internet o a la red interna cuando no debería). Al combinar el análisis de código y las pruebas, puede detectar las debilidades de SSRF de forma temprana, antes de que un atacante utilice su aplicación como proxy.

10. Deserialización insegura

Qué es: La deserialización insegura es una vulnerabilidad más especializada, pero increíblemente peligrosa cuando existe. Se produce cuando una aplicación deserializa datos de una fuente no fiable. sin la validación adecuada – lo que significa que toma algunos datos binarios o estructurados (como objetos, JSON/XML o blobs binarios) del cliente y reconstruye un objeto en la memoria. Ciertos formatos de serialización (especialmente en lenguajes como Java, .NET, Python o PHP) pueden utilizarse indebidamente para ejecutar código durante el proceso de deserialización. Los atacantes crean objetos serializados maliciosos (a menudo denominados «cadenas de gadgets») que, cuando el servidor los deserializa, activan comandos o comportamientos elegidos por el atacante. Esto puede dar lugar a la ejecución remota de código o a la manipulación lógica en el servidor, sin necesidad siquiera de un fallo de inyección normal. Las vulnerabilidades de deserialización insegura son esencialmente bombas lógicas ocultas en los datos. Se destacaron en el Top 10 OWASP y siguen siendo relevantes, aunque el Top 10 de 2021 lo amplió a «Fallos de integridad de software y datos». Si una aplicación acepta cualquier tipo de objetos serializados (como Java Serializable objetos, ViewState de .NET o incluso cierto JSON con información de tipo de clase) de los usuarios, podría estar en riesgo.

Ejemplo: Un ejemplo reciente que está causando revuelo es CVE-2025-55182 en los componentes del servidor React (divulgado en diciembre de 2025). Se trataba de un RCE crítico que resultó estar causado por una deserialización insegura en el protocolo React Server Components. Básicamente, un atacante podía enviar una carga HTTP malformada que el lado del servidor React deserializaría incorrectamente, lo que permitía la ejecución de código arbitrario. Tenía un CVSS 10 y afectaba a un gran número de aplicaciones (dada la gran difusión de React). Esto demuestra que ni siquiera los marcos más avanzados son inmunes a los problemas de deserialización. Otro ejemplo clásico: el Explotación de Java Commons Collections en 2016 – Una deserialización insegura en muchas aplicaciones Java (a través de una biblioteca) permitía a los atacantes enviar un objeto serializado que, al deserializarse, ejecutaba comandos en el servidor. Esto se explotó ampliamente en productos como Jenkins, WebLogic, etc. En .NET, existía la vulnerabilidad de deserialización de ViewState (CVE-2017-8759) y otras en las que los datos no saneados en un estado de vista provocaban RCE. Las aplicaciones PHP han tenido problemas cuando unserialize() se invoca con la entrada del usuario. Incluso JavaScript (Node.js) tenía uno muy conocido en el serializar-javascript paquete. Así que, desde los sistemas empresariales hasta los marcos modernos, la deserialización insegura aparece a menudo con graves consecuencias.

Impacto: La deserialización insegura suele ser una vía directa para la ejecución remota de código (RCE). Es lo peor que puede pasar: el atacante puede ejecutar código arbitrario en tu servidor, lo que le permite tomar el control total del mismo. Incluso si no se trata de una RCE completa, los fallos de deserialización pueden utilizarse para manipular la lógica (por ejemplo, alterando las estructuras de datos para obtener mayores privilegios sobre los datos de los objetos). Pero, por lo general, el impacto es crítico: si un atacante puede explotarlo, a menudo puede colocar un webshell, crear un usuario backdoor o adentrarse más en la red. El peligro se ve amplificado por el hecho de que los exploits de deserialización a menudo no requieren autenticación (si la aplicación está deserializando datos antes de la autenticación) y se pueden realizar con una sola solicitud. Es una forma sigilosa de entrar: sin consultas SQL sospechosas ni scripts entre sitios, solo un blob de datos aparentemente inocuo que hace explotar tu aplicación desde dentro.

Prevención: La mejor manera de evitar la deserialización insegura es no deserializar nunca datos que no sean de confianza. Si no es absolutamente necesario aceptar objetos serializados de los usuarios, no lo haga. Utilice formatos de datos más seguros (por ejemplo, JSON, sin metadatos de tipo de clase que puedan invocar constructores arbitrarios). Si necesita serializar/deserializar, considere la posibilidad de implementar comprobaciones de integridad: por ejemplo, firme los datos serializados o incluya un MAC, de modo que se pueda detectar cualquier manipulación. Algunos marcos permiten restringir las clases que se pueden deserializar (clases de lista de permitidos). Esto puede impedir que funcionen cadenas de gadgets arbitrarias. Mantenga las bibliotecas actualizadas, ya que muchos fallos de deserialización se corrigen reforzando el código que se ejecuta durante la construcción de objetos. OWASP también sugiere aislar el proceso de deserialización, tal vez ejecutándolo en un entorno con pocos privilegios o en un entorno aislado, de modo que si se activa un exploit, el impacto sea mínimo. En general, trate los datos serializados como potencialmente hostiles. Además, tenga en cuenta la serialización oculta, como en las comunicaciones entre servicios o en las cachés.

La inteligencia y el análisis de vulnerabilidades de Aikido pueden ayudar a detectar estos problemas. En cuanto al análisis estático, Aikido puede señalar el uso de funciones o patrones peligrosos, por ejemplo, el uso de ObjectInputStream.readObject() en Java o PHP unserialize() sobre los datos de los usuarios o bibliotecas de deserialización inseguras que se sabe que son explotables. Te avisará diciendo: «Oye, estás deserializando algo aquí, ¿es seguro?». análisis de dependencias de Aikido análisis de dependencias entra en juego: puede alertarte si estás utilizando una versión de biblioteca que se sabe que tiene una vulnerabilidad de deserialización (por ejemplo, una versión obsoleta de una biblioteca de serialización común). Si surge un CVE importante como el CVE-2025-55182 (el de React), inteligencia de amenazas de Aikido (como Aikido Intel) destacarían cuáles de tus proyectos podrían verse afectados y necesitar un parche. En términos de pruebas, esto es más difícil para los escáneres dinámicos, pero Aikido Attack podría intentar cargas útiles de explotación conocidas si su aplicación utiliza un marco común conocido por un error de deserialización. En última instancia, la mitigación suele requerir cambios en el código o actualizaciones de la biblioteca, y la función de Aikido es hacerle consciente del riesgo rápidamente. Al detectar la deserialización insegura durante el desarrollo o el escaneo, puede refactorizar para utilizar formatos de datos seguros o actualizar a versiones parcheadas. antes de desplegar una bomba de relojería.

Creación de una postura segura para aplicaciones web

Como hemos visto, las aplicaciones web actuales se enfrentan a multitud de vulnerabilidades, desde fallos de inyección pueden vaciar su base de datos, hasta fallos lógicos que permiten a los atacantes burlar su autorización, pasando por fugas de secretos y riesgos de dependencia que provienen de las herramientas en las que confiamos. Puede parecer abrumador, pero el denominador común es la concienciación y la defensa proactiva. Al comprender estas vulnerabilidades principales, ya está un paso por delante en su mitigación.

Algunas conclusiones clave para una postura de seguridad sólida en las aplicaciones web:

• Desplazar la seguridad hacia la izquierda: detectar los problemas en las primeras fases del desarrollo. Integrar SASTSCA (como Aikido) en su canalización de CI y su IDE, para que las vulnerabilidades se marquen y se corrijan antes de fusionar el código. Es mucho más fácil corregir una consulta SQL insegura o añadir una comprobación de autenticación durante la codificación que tener que apresurarse después de una brecha.
• Defensas por capas: utilice múltiples capas de controles de seguridad. Por ejemplo, para evitar inyecciones y XSS, combine prácticas de codificación seguras con bibliotecas de seguridad y ejecute también un firewall de aplicaciones web firewall de aplicaciones WAF) para obtener una protección adicional. Para la autenticación, aplique la autenticación multifactorial (MFA) y utilice la supervisión para detectar inicios de sesión sospechosos. La defensa en profundidad significa que, incluso si una capa falla, las demás detectan el problema.
• Manténgase al día: mantenga actualizadas las dependencias y los servidores. Considere la posibilidad de habilitar las actualizaciones automáticas para los componentes críticos cuando sea posible. Aproveche las fuentes o plataformas de vulnerabilidades (Aikido, Dependabot, etc.) para saber cuándo tiene algo vulnerable en su pila. Cuanto más rápido solucione los problemas conocidos, menos probabilidades tendrá de verse afectado por campañas de explotación masiva.
• Gestión de secretos y privilegios mínimos: trate las credenciales como si fueran joyas de la corona. Utilice almacenes o configuraciones de entorno para los secretos, rótelos periódicamente y conceda a cada servicio el acceso mínimo que necesite. De este modo, aunque se vea comprometida una clave, se limitará el alcance del daño.
• Seguridad desde el diseño: incorpore modelos de amenazas y principios de diseño seguro desde el principio. En el caso de las nuevas funciones, considere cómo podrían utilizarse de forma indebida e incorpore los controles necesarios (por ejemplo, asegúrese de que una nueva función de carga de archivos valide los tipos y tamaños de los archivos para evitar problemas de deserialización o DoS, asegúrese de que un nuevo punto final de la API compruebe las funciones de los usuarios para evitar fallos en el control de acceso, etc.).
• Educar y automatizar: Mantenga al equipo de desarrollo informado sobre los errores más comunes (como los que aparecen en Top 10 OWASP). Utilice escáneres y pruebas automatizadas como red de seguridad, pero fomente también una cultura en la que los desarrolladores piensen en el impacto de la seguridad. Un poco de concienciación ayuda mucho a evitar, por ejemplo, la tentación de desactivar los tokens CSRF «solo para probar» o copiar y pegar código de StackOverflow sin tener en cuenta la seguridad.

Si se centra en estas prácticas básicas, podrá reducir drásticamente el perfil de riesgo de su aplicación. Muchos ataques tienen éxito no porque sean extremadamente sofisticados, sino porque se han descuidado las medidas básicas de seguridad. Si subsana esas deficiencias, los atacantes pasarán a objetivos más fáciles.

Conclusión

Crear aplicaciones web que puedan hacer frente a las amenazas actuales está totalmente al alcance de los equipos de desarrollo, especialmente si cuentan con las herramientas adecuadas. Hemos repasado las principales vulnerabilidades web que afectan a las aplicaciones y hemos visto cómo se traducen en incidentes reales. El denominador común es que la concienciación y la detección temprana marcan la diferencia. Cuando se sabe qué hay que buscar, ya sea una entrada no saneada, una comprobación de acceso que falta o una biblioteca obsoleta, se puede abordar de forma proactiva en lugar de reactiva.

Como desarrollador o DevSecOps , no tienes por qué afrontar esto solo. AppSec modernas AppSec , como Aikido Security , están diseñadas para integrarse perfectamente en su flujo de trabajo y detectar rápidamente estos problemas. Imagine tener un experto en seguridad automatizado que revise cada compromiso: señalando ese sigiloso error XSS, detectando la clave AWS antes de que salga de su ordenador portátil, señalando que está utilizando una versión de una biblioteca con un CVE crítico e incluso sugiriendo o aplicando correcciones. Eso es lo que ofrece Aikido: un análisis todo en uno de código, dependencias, configuración y mucho más, creado para desarrolladores. Es como tener Top 10 OWASP la última base de datos CVE velando por ti, sin ralentizarte.

Próximos pasos: No espere a que se produzca una auditoría o (peor aún) una infracción para detectar estas vulnerabilidades. Puede empezar por realizar un análisis de seguridad en su código base para ver cuál es su situación. Configure reglas de linting para la seguridad, añada comprobaciones de dependencias y habilite la autenticación de dos factores (2FA) en todas partes. Si le interesa una plataforma centrada en los desarrolladores que haga todo esto y mucho más, considere probar Aikido, que ofrece análisis de código, SAST, detección de secretos, IaC y análisis de contenedores, además de correcciones asistidas por IA en una interfaz unificada. De hecho, Aikido puede comparar automáticamente el estado de su proyecto con Top 10 OWASP y ayudarle a cerrar las brechas.

Al final, el objetivo es integrar la seguridad en la estructura del desarrollo. Al centrarse en estas vulnerabilidades principales, escribir código seguro y utilizar herramientas para automatizar las tareas más pesadas, reducirá significativamente el riesgo para sus aplicaciones web. Los datos de sus usuarios permanecerán seguros, su aplicación seguirá funcionando y usted podrá dormir un poco más tranquilo por la noche (¡al igual que el 42 % de los equipos que seguían preocupándose por la seguridad de los contenedores y las aplicaciones, como se ha mencionado anteriormente!).