10 Vulnerabilidades Web Comunes y Cómo Solucionarlas

La seguridad web no es un lujo; es una necesidad absoluta. Cada día, miles de sitios web —personales, online o de comercio electrónico— son víctimas de ciberataques. A veces, estos ataques pasan desapercibidos durante semanas. Otras veces, provocan pérdida de datos, robo de información confidencial o incluso interrupciones totales del sitio web.

Si tienes un sitio web, incluso uno pequeño, eres un objetivo potencial. Los hackers no solo atacan a grandes empresas; automatizan sus ataques y buscan las vulnerabilidades web más fáciles de explotar. Un simple descuido en tu código o configuración del servidor puede ser suficiente para abrirles la puerta.

En esta guía, exploraremos los 10 tipos de vulnerabilidades web más comunes, cómo funcionan y, lo más importante, cómo evitarlas. Esta guía está diseñada para profesionales técnicos que buscan reforzar sus conocimientos en seguridad defensiva. Comprenderás claramente qué sucede, por qué es peligroso y qué puedes hacer para protegerte.

Las 10 vulnerabilidades web más comunes que se abordan en esta guía son:

1. Inyección SQL (SQLi)
2. Cross-Site Scripting (XSS)
3. Autenticación y Gestión de Sesiones Inseguras
4. Mala Gestión de Carga de Archivos
5. Configuraciones de Seguridad deficientes
6. Falsificación de Solicitud entre Sitios (CSRF)
7. Uso de Componentes con Vulnerabilidades Conocidas
8. Acceso sin Restricciones a Archivos Sensibles
9. Almacenamiento de Contraseñas en Texto Plano
10. Falta de Actualizaciones y Monitoreo

1. Inyección SQL: la vulnerabilidad más conocida y más peligrosa

La inyección SQL es probablemente la vulnerabilidad más conocida en la web. Consiste en explotar una debilidad en una consulta SQL para ejecutar código malicioso directamente en la base de datos.

Veamos un ejemplo sencillo. Imaginemos que tenemos una página de inicio de sesión con un formulario donde el usuario introduce su nombre de usuario y contraseña. En PHP, podríamos tener la tentación de escribir una consulta como esta:

$requete = "SELECT * FROM users WHERE pseudo = '" . $_POST['pseudo'] . "' AND password = '" . $_POST['password'] . "'";

Si el usuario malintencionado ingresa el siguiente texto en el campo de nombre de usuario:

' OR '1'='1

La solicitud queda así:

SELECT * FROM users WHERE pseudo = '' OR '1'='1' AND password = '';

Resultado: la condición '1'='1' sigue siendo verdadera y el atacante puede iniciar sesión sin saber una contraseña.

¿Por qué es peligroso?

Porque el atacante puede ir mucho más allá: eliminar datos, leer contraseñas o incluso tomar el control total de tu base de datos.

🔍 Cómo se detecta:

Un auditor suele probar inyectando caracteres especiales como comillas simples (') o comillas dobles (") en los campos de entrada. Si el servidor devuelve un error de base de datos visible en pantalla o el comportamiento de la página cambia drásticamente, es una señal clara de que existen vulnerabilidades en páginas web.

¿Cómo puedes protegerte?

Simplemente usa consultas preparadas o parametrizadas. En PHP, por ejemplo, con PDO, tal como se detalla en la documentación oficial de PHP:

$stmt = $pdo->prepare("SELECT * FROM users WHERE pseudo = :pseudo AND password = :password");
$stmt->execute(['pseudo' => $_POST['pseudo'], 'password' => $_POST['password']]);

Aquí, el contenido ingresado por el usuario ya no se inyecta directamente en la consulta SQL: se trata como datos simples y no como código ejecutable.

Para protegerte, puedes utilizar herramientas como un escáner de vulnerabilidades de inyección SQL para identificar estos fallos.

2. Cross-Site Scripting (XSS): el arte de inyectar código en tus páginas

El Cross-Site Scripting (XSS) es una vulnerabilidad muy común que permite a un atacante inyectar código JavaScript malicioso en una página web. Este código puede ejecutarse posteriormente en el navegador de tus visitantes.

Tomemos un ejemplo: tu sitio muestra los comentarios dejados por los usuarios sin verificar su contenido. Si un visitante malintencionado introduce el siguiente mensaje:

<script>alert('¡Has sido hackeado!');</script>

Entonces, cada vez que otro usuario visualice este comentario, el script se ejecutará en su navegador.

Aunque este ejemplo pueda parecer inofensivo, el atacante podría, en su lugar, robar las cookies de sesión, redirigir a los visitantes a un sitio fraudulento o inyectar un formulario falso para robar contraseñas.

¿Por qué es peligrosa?

Porque el código se ejecuta del lado del cliente (en el navegador). Por lo tanto, es muy difícil para tus visitantes darse cuenta de que son víctimas de un script malicioso proveniente de tu propio sitio.

🔍 Cómo se detecta:

Los pentesters intentan inyectar payloads básicos como <script>alert(1)</script> o etiquetas <h1>Test</h1> en comentarios y formularios. Si el navegador renderiza la etiqueta HTML o ejecuta la alerta en lugar de mostrar el texto plano, el sitio es vulnerable a XSS reflejado o almacenado. Detectar vulnerabilidades web de este tipo es crucial para la seguridad del usuario.

¿Cómo protegerte?

Siempre se deben filtrar y escapar los datos antes de mostrarlos. En PHP, la función htmlspecialchars() es esencial:

echo htmlspecialchars($comentario);

Esta función impide que el navegador interprete las etiquetas HTML como código, neutralizando así los intentos de scripting.

Además, se recomienda utilizar encabezados HTTP como Content-Security-Policy para restringir los scripts autorizados en tu sitio.

3. Vulnerabilidades de autenticación y gestión de sesiones

La seguridad no se limita al código; también depende de cómo los usuarios se identifican y mantienen su conexión. Las vulnerabilidades de autenticación se encuentran entre las más explotadas, ya que permiten a un atacante suplantar la identidad de otro usuario.

Un caso típico es el de la contraseña débil. Muchos usuarios eligen contraseñas simples como “azerty123” o “admin”. Estas combinaciones pueden ser adivinadas o probadas muy rápidamente mediante ataques de fuerza bruta (donde un programa prueba miles de combinaciones por segundo).

Otro problema frecuente se relaciona con la gestión de sesiones. Cuando un usuario inicia sesión, se crea una sesión para reconocerlo en las páginas siguientes. Si esta sesión está mal asegurada, un atacante puede robarla. Esto puede ocurrir, por ejemplo, si la cookie de sesión no está cifrada o si el sitio no fuerza el uso del protocolo HTTPS.

¿Por qué es peligrosa?

Porque una vez robada la sesión, el atacante puede actuar exactamente como si fuera el usuario: modificar su perfil, acceder a datos personales o administrar el sitio.

🔍 Cómo se detecta:

Se analizan las cookies en las herramientas de desarrollador del navegador (F12). Si la bandera HttpOnly o Secure está ausente en la cookie de sesión, o si el sitio permite el acceso a áreas privadas mediante HTTP sin redirigir automáticamente a HTTPS, existe un riesgo inmediato de secuestro de sesión.

¿Cómo protegerte?

• Forzar las conexiones a través de HTTPS para cifrar el intercambio de datos entre el navegador y el servidor.
• Generar identificadores de sesión aleatorios y difíciles de predecir.
• Utilizar cookies seguras con los atributos HttpOnly (para impedir el acceso desde JavaScript) y Secure (para que solo se envíen a través de HTTPS).
• Exigir contraseñas robustas: al menos 12 caracteres, combinando mayúsculas, minúsculas, números y símbolos.
• Para los sitios que gestionan cuentas, es aconsejable implementar la autenticación de dos factores (2FA). Incluso si una contraseña se filtrara, el atacante no podría iniciar sesión sin el código secundario (a menudo enviado por SMS o a través de una aplicación).

4. Mala gestión de descargas de archivos: abre la puerta a los ejecutables

Permitir que los usuarios suban archivos (imágenes, CV, documentos) es una funcionalidad muy común. Sin embargo, es una de las más riesgosas si no se protege adecuadamente. Un archivo que se supone que es una imagen puede contener en realidad código ejecutable o tener una extensión disfrazada.

Un atacante puede así depositar un script en el servidor y luego ejecutarlo desde la web para tomar el control. El abuso de la funcionalidad de carga de archivos es una técnica de explotación conocida.

Un ejemplo concreto: un formulario acepta únicamente “.jpg” pero no verifica el contenido del archivo. El atacante renombra un archivo PHP a “foto.jpg.php” o modifica las cabeceras para engañar la verificación. Si el servidor ejecuta posteriormente este archivo, el atacante puede ejecutar cualquier comando.

🔍 Cómo se detecta:

Durante una auditoría, se intenta subir un archivo con doble extensión (ej. shell.php.jpg) o cambiar el Magic Number del archivo interceptando la petición con un proxy. El objetivo es ver si el servidor valida solo por extensión superficial y no por el contenido real del archivo.

¿Cómo protegerte?

Primero, valida el tipo MIME del archivo en el lado del servidor y no solo en el lado del cliente. Luego, almacena los archivos subidos fuera del directorio web público o en una carpeta donde la ejecución de scripts esté desactivada. Renombra sistemáticamente los archivos con un identificador aleatorio y rechaza las extensiones potencialmente peligrosas.

Finalmente, si se debe mostrar una imagen, recodifícala en el lado del servidor (por ejemplo, abriendo y guardando la imagen de nuevo) para eliminar cualquier contenido oculto. Limitar el tamaño de los archivos y escanearlos con un antivirus en el servidor añade una capa adicional de seguridad.

5. Configuraciones deficientes del servidor: la vulnerabilidad costosa

Un servidor mal configurado puede exponer información sensible sin que ninguna línea de código sea vulnerable. Listados de directorios, archivos de respaldo accesibles, versiones de software visibles o permisos demasiado amplios facilitan el trabajo de un atacante.

Ilustración: si el servidor muestra por error el índice de una carpeta, un atacante puede listar la estructura de archivos y encontrar ficheros de configuración (.env, config.php) que contienen contraseñas y claves. De igual manera, dejar activados servicios innecesarios o puertos abiertos multiplica los puntos de entrada.

🔍 Cómo se detecta:

Herramientas de escaneo automatizado o simplemente inspeccionar las cabeceras HTTP de respuesta (como Server o X-Powered-By) suelen revelar versiones específicas de software. Si un servidor responde mostrando listados de carpetas (“Index of /”), indica una configuración por defecto no asegurada.

Medidas concretas: oculta las versiones de los servidores, deshabilita la navegación en los directorios, limita estrictamente los permisos de los archivos (por ejemplo, 640 o 600 para archivos sensibles), cierra los puertos no utilizados y utiliza un firewall de aplicaciones web (WAF) para filtrar las solicitudes maliciosas. Documentar y automatizar la configuración (Infrastructure as Code) reduce los errores humanos.

6. Falsificación de solicitud entre sitios (CSRF): actuar sin darse cuenta

El CSRF permite a un atacante hacer que un usuario autenticado ejecute una acción en tu sitio sin que este sea consciente de ello. Por ejemplo, si un usuario está conectado a su portal bancario y visita un sitio malicioso, este último puede enviar una solicitud al sitio del banco para transferir dinero, y el navegador incluirá automáticamente las cookies de sesión, validando la solicitud.

Ejemplo simple: un formulario para modificar el correo electrónico que no verifica el origen de la solicitud puede ser activado por un formulario oculto en otra página.

🔍 Cómo se detecta:

Al inspeccionar el código fuente de un formulario crítico (Ctrl+U), si no encuentras un campo oculto con un token aleatorio (o anti-CSRF) y la aplicación solo confía en las cookies de sesión para validar la acción, es altamente probable que sea explotable mediante CSRF. Saber cómo encontrar vulnerabilidades en una página web como esta requiere revisar la lógica de validación de las solicitudes.

Prevención: cada formulario que proponga una acción sensible debe incluir un token CSRF único y verificable en el lado del servidor. Este token se genera para la sesión del usuario y debe estar presente y ser válido en el momento de la recepción. Para las solicitudes AJAX, el token puede enviarse en una cabecera personalizada. Además, verificar la cabecera Origin o Referer puede ayudar, pero no es suficiente por sí solo.

7. Vulnerabilidades en bibliotecas o complementos de terceros: la deuda técnica recurrente

El uso de bibliotecas, frameworks o plugins acelera el desarrollo. Pero cada componente añadido es una superficie de ataque potencial. Las vulnerabilidades conocidas en bibliotecas comunes (gestores de imágenes, extensiones de CMS, componentes JS) son a menudo explotadas de forma automatizada por escáneres de ataque.

Caso común: un plugin de un CMS ya no recibe mantenimiento y contiene una vulnerabilidad que permite obtener acceso de administrador. En cientos de sitios que utilizan este plugin, los ataques automatizados se centran en esta debilidad.

🔍 Cómo se detecta:

Se pueden identificar las versiones de librerías (como jQuery o plugins de WordPress) mirando el código fuente de la página. Luego, se consultan bases de datos públicas como CVE Details para ver si esa versión exacta tiene exploits reportados.

¿Qué hacer?

Actualiza regularmente todas las dependencias, monitorea los anuncios de seguridad de los proyectos que utilizas y elimina los plugins innecesarios. Cuando sea posible, prioriza bibliotecas con mantenimiento activo y populares. Integrar una herramienta de análisis de vulnerabilidades en dependencias (SCA) en el proceso de despliegue ayuda a detectar automáticamente las versiones vulnerables.

8. Acceso sin restricciones a archivos sensibles: exposición no intencionada

En el servidor pueden existir archivos sensibles: copias de seguridad, archivos de configuración, claves de API, exportaciones CSV. Si estos archivos son de acceso público, se convierten en una mina de oro para un atacante.

Ejemplo: un archivo backup.sql dejado en una carpeta pública contiene la estructura y los datos de la base de datos. Un robot puede descargarlo y extraer credenciales.

🔍 Cómo se detecta:

Utilizando técnicas de fuzzing de directorios (buscando rutas comunes como /backup, .git, o .env) se comprueba si el servidor devuelve un código 200 OK. Si puedes descargar el archivo directamente desde el navegador, la falla está confirmada. El proceso para encontrar vulnerabilidades en páginas web a menudo incluye la búsqueda de estos archivos expuestos.

Medidas: coloca los archivos sensibles fuera de la raíz web (web root), o aplica reglas de acceso estrictas a través del servidor web (reglas de reescritura, protección por contraseña para zonas de administración). Cifra las copias de seguridad y limita el acceso mediante cuentas dedicadas. Finalmente, automatiza la purga de archivos antiguos para reducir la exposición.

9. Almacenar contraseñas en texto plano: un error crítico

Almacenar las contraseñas de los usuarios en texto plano en la base de datos es una práctica peligrosa. En caso de una filtración de datos, todos los accesos quedan expuestos inmediatamente. Los usuarios a menudo reutilizan sus credenciales, lo que amplía el impacto.

La buena práctica consiste en no almacenar nunca una contraseña en texto plano, sino su huella (hash), utilizando un algoritmo adaptado para contraseñas, como Argon2 o bcrypt, con una sal (salt) única por usuario. Estos algoritmos hacen que la recuperación de la contraseña original sea extremadamente costosa en tiempo y recursos.

🔍 Cómo se detecta:

Si al utilizar la función “Olvidé mi contraseña” el sitio te envía tu contraseña antigua por correo electrónico en lugar de un enlace para generar una nueva, es la prueba definitiva de que no están cifradas (hasheadas) y se guardan en texto plano.

Ejemplo de implementación en PHP: utiliza password_hash() y password_verify(), que encapsulan bcrypt/argon2 según la configuración. Paralelamente, implementa políticas de contraseñas robustas y ofrece la opción de restablecimiento por correo electrónico en lugar de enviar la contraseña actual.

10. Falta de actualizaciones y seguimiento: el desgaste del tiempo

Un sitio no actualizado o no monitoreado termina acumulando vulnerabilidades. Los parches de seguridad se publican regularmente; no aplicarlos es dejar la puerta abierta. Al mismo tiempo, la ausencia de registros (logs) y alertas impide detectar una intrusión a tiempo.

🔍 Cómo se detecta:

Similar a las configuraciones, el “banner grabbing” permite ver si el servidor corre un sistema operativo o servicio (como Apache o Nginx) con años de antigüedad. Además, si realizas pruebas de ataque controlado y no recibes ninguna alerta de bloqueo, confirma la falta de monitoreo activo.

Medidas prácticas: establece una política de actualizaciones regulares para el sistema operativo, el servidor web, el lenguaje de programación y las dependencias. Automatiza los despliegues cuando sea posible. Instala herramientas de monitoreo que alerten en caso de actividad anómala (logs de acceso, errores 500 masivos, intentos de conexión repetidos). Conserva copias de seguridad fuera del sitio y prueba los procedimientos de restauración para asegurar su funcionamiento.

Convertir la seguridad en un hábito

Proteger un sitio web no es un ritual puntual, sino un estado mental. Las vulnerabilidades web presentadas aquí —inyección SQL, XSS, configuraciones incorrectas, gestión de archivos, CSRF, componentes de terceros, acceso a archivos sensibles, contraseñas en texto plano y falta de actualizaciones— son responsables de la mayoría de las brechas de seguridad. A menudo aparecen por falta de vigilancia, procedimientos o automatización.

El siguiente paso es hacer que la seguridad sea práctica y repetible. Implementa un proceso simple y documentado: verifica las dependencias antes de cada despliegue, automatiza las copias de seguridad, aplica las actualizaciones críticas, controla el acceso a los archivos y añade protecciones básicas como HTTPS, CSP, tokens CSRF y el hashing de contraseñas. Monitorea los logs y considera analizar vulnerabilidades web de forma regular.

Y, sobre todo, considera la seguridad como una inversión: unas pocas horas dedicadas a configurar correctamente un servidor o a corregir un plugin son preferibles a semanas de recuperación tras un incidente.

Para poner en práctica estos conceptos en un entorno seguro, te recomendamos explorar diferentes sitios web vulnerables para pentesting. Si durante tus auditorías descubres un fallo, aquí te explicamos qué hacer cuando encuentras una vulnerabilidad.

Para profundizar, explorar recursos especializados (las recomendaciones de OWASP, guías de configuración del servidor web, herramientas de análisis automático) permite estructurar un enfoque sostenible. Aplicando progresivamente estas buenas prácticas, es posible reducir drásticamente el riesgo y ofrecer a los visitantes un sitio más fiable y seguro.