Auditoría de Seguridad de una Web: Guía Paso a Paso 2026

📘 Este artículo forma parte de nuestra Guía Completa de Ciberseguridad 2026 y de nuestra Guía Completa de Hacking Ético 2026. Si quieres dominar la seguridad web desde dentro, esas guías son tu punto de partida.

Introducción

Cada día se descubren miles de vulnerabilidades web en todo el mundo. Desde inyecciones SQL hasta XSS, pasando por configuraciones incorrectas y APIs mal protegidas, las aplicaciones web son uno de los principales objetivos de los atacantes.

Una auditoría de seguridad de una web es un proceso sistemático que evalúa la seguridad de una aplicación web: su código, su infraestructura, sus comunicaciones, sus accesos y sus procesos. El objetivo no es solo encontrar vulnerabilidades, sino entender el riesgo real y recomendar soluciones concretas.

En 2026, con la llegada de la IA ofensiva, el phishing perfecto y las cadenas de suministro comprometidas, las auditorías web ya no son opcionales: son imprescindibles para cualquier negocio con presencia online.

En esta guía completa vas a aprender:

• Qué es una auditoría de seguridad web y su diferencia con un pentest web.
• Metodología paso a paso siguiendo los estándares OWASP.
• Reconocimiento y fingerprinting de la aplicación.
• Análisis de vulnerabilidades y validación manual.
• OWASP Top 10 aplicado a la práctica.
• Herramientas esenciales con comandos reales.
• Cómo redactar un informe de auditoría web.
• Checklist completo de auditoría web.
• Troubleshooting de problemas comunes.
• FAQ con las preguntas más frecuentes.

Si te interesa el pentesting específicamente, consulta nuestra Guía Completa de Hacking Ético. Para auditorías generales, nuestra Guía de auditoría de ciberseguridad.

Índice de contenidos

1. ¿Qué es una auditoría de seguridad web?
2. Diferencias con el pentesting web
3. OWASP: el estándar de referencia
4. Fases de una auditoría web
5. Reconocimiento y fingerprinting
6. Análisis de vulnerabilidades
7. OWASP Top 10 en la práctica
8. Herramientas esenciales
9. Cómo redactar el informe
10. Checklist completo
11. Troubleshooting
12. FAQ
13. Conclusión

1. ¿Qué es una auditoría de seguridad web?

Una auditoría de seguridad web es un proceso sistemático y documentado que evalúa la seguridad de una aplicación web en todas sus capas:

• Frontend — HTML, JavaScript, CSS.
• Backend — servidor, API, lógica de negocio.
• Base de datos — estructura, consultas, accesos.
• Infraestructura — servidor web, SO, red.
• Configuración — cabeceras, SSL/TLS, permisos.
• Procesos — autenticación, sesiones, gestión de errores.

Objetivos principales:

1. Identificar vulnerabilidades en la aplicación.
2. Evaluar su impacto real en el negocio.
3. Priorizar según criticidad.
4. Recomendar mitigaciones concretas.
5. Cumplir con normativas (RGPD, PCI-DSS, NIS2).
6. Prevenir brechas antes de que ocurran.

¿Por qué es crítico en 2026?

• El 43% de las brechas ocurren a través de aplicaciones web.
• El coste medio de una brecha supera los 4,8 millones de dólares.
• La regulación europea (NIS2, DORA) exige auditorías periódicas.
• La IA ofensiva permite automatizar ataques a escala.
• Los usuarios confían sus datos a webs sin garantías.

Consulta nuestra Guía Completa de Ciberseguridad para el contexto general de amenazas.

2. Diferencias con el pentesting web

Aunque se confunden, son cosas distintas:

En la práctica:

• Auditoría: visión global + cumplimiento.
• Pentesting: validación técnica profunda.

Una auditoría puede incluir un pentesting, pero no al revés.

Consulta nuestra Guía de pruebas de penetración en aplicaciones web.

3. OWASP: el estándar de referencia

OWASP (Open Web Application Security Project) es la organización de referencia mundial en seguridad web. Mantiene varios estándares clave:

3.1 OWASP Top 10

Lista de las 10 vulnerabilidades web más críticas:

3.2 OWASP ASVS

Application Security Verification Standard. Define 3 niveles de requisitos:

• L1: básico (todas las apps).
• L2: defensivo (apps con datos sensibles).
• L3: avanzado (apps críticas).

3.3 OWASP Testing Guide (WSTG)

Guía técnica con +100 tests específicos para verificar cada vulnerabilidad.

3.4 OWASP ZAP

Herramienta open source para pentesting web.

Recursos:

• Top 10: https://owasp.org/Top10/
• ASVS: https://owasp.org/www-project-application-security-verification-standard/
• WSTG: https://owasp.org/www-project-web-security-testing-guide/
• ZAP: https://www.zaproxy.org/

Recomendación: usa Top 10 como checklist, ASVS como estándar y WSTG como guía técnica.

4. Fases de una auditoría web

Una auditoría profesional sigue 6 fases:

4.1 Fase 1: Planificación

• Definir alcance: URL, subdominios, APIs.
• Firmar contratos (NDA, RoE).
• Establecer ventanas de prueba.
• Preparar entorno y credenciales.

Documentos clave:

• Contrato de auditoría.
• NDA.
• RoE.
• Alcance detallado.

4.2 Fase 2: Reconocimiento

• Fingerprinting de tecnologías.
• Enumeración de endpoints y directorios.
• Identificación de APIs.
• Análisis de cabeceras.

Herramientas: Nmap, WhatWeb, Wappalyzer, Gobuster.

4.3 Fase 3: Análisis de vulnerabilidades

• Escaneo automatizado (Burp Scanner, ZAP).
• Validación manual de hallazgos.
• Análisis de código (si es white box).

Herramientas: Burp Suite, ZAP, Nikto, sqlmap.

4.4 Fase 4: Explotación (opcional)

• Explotar vulnerabilidades confirmadas.
• Escalar privilegios.
• Documentar con PoC.

Herramientas: Metasploit, sqlmap, Burp Intruder.

4.5 Fase 5: Análisis de infraestructura

• Revisión del servidor web.
• Análisis de SSL/TLS.
• Revisión de configuración (headers, métodos HTTP).

Herramientas: testssl.sh, SSL Labs, Nikto.

4.6 Fase 6: Reporte

• Clasificar hallazgos por severidad.
• Documentar con evidencias.
• Recomendar mitigaciones.
• Presentar al cliente.

Consulta nuestra Guía de auditoría de ciberseguridad para el marco general.

5. Reconocimiento y fingerprinting

5.1 Fingerprinting de tecnologías

WhatWeb:

whatweb https://example.com

whatweb https://example.com

Detecta: CMS, frameworks, servidor web, lenguaje, librerías.

Wappalyzer:

• Extensión de navegador.
• Identifica tecnologías al navegar.

Nmap con scripts HTTP:

nmap -sV -p 80,443 --script http-title,http-headers,http-enum example.com

nmap -sV -p 80,443 --script http-title,http-headers,http-enum example.com

5.2 Enumeración de directorios

Gobuster:

gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt -t 50

gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt -t 50

ffuf:

ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt

ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt

Feroxbuster:

feroxbuster -u https://example.com -w /usr/share/wordlists/dirb/common.txt

feroxbuster -u https://example.com -w /usr/share/wordlists/dirb/common.txt

Wordlists recomendadas:

• SecLists: https://github.com/danielmiessler/SecLists

5.3 Enumeración de subdominios

# Amass
amass enum -d example.com

# Sublist3r
sublist3r -d example.com

# Subfinder
subfinder -d example.com

# Amass
amass enum -d example.com

# Sublist3r
sublist3r -d example.com

# Subfinder
subfinder -d example.com

5.4 Análisis de cabeceras HTTP

curl -I https://example.com

curl -I https://example.com

Buscar:

• Server (versión del servidor web).
• X-Powered-By (lenguaje/framework).
• Set-Cookie (atributos de seguridad).
• Security Headers: HSTS, CSP, X-Frame-Options.

5.5 Análisis de robots.txt y sitemap.xml

curl https://example.com/robots.txt
curl https://example.com/sitemap.xml

curl https://example.com/robots.txt
curl https://example.com/sitemap.xml

Revela:

• Directorios «ocultos».
• Rutas internas.
• Recursos prohibidos.

5.6 Análisis de tecnologías con tecnología específica

• CMS: WordPress, Joomla, Drupal.
• Frameworks: Laravel, Django, Rails.
• Lenguajes: PHP, Python, Node.js.
• Bases de datos: MySQL, PostgreSQL, MongoDB.

Consulta nuestra Guía de reconocimiento y OSINT.

6. Análisis de vulnerabilidades

6.1 Escaneo automatizado

Burp Suite Scanner:

1. Configurar proxy.
2. Navegar la aplicación.
3. Lanzar Active Scan.
4. Revisar hallazgos.

OWASP ZAP:

zap-cli quick-scan --self-contained --start-options '-config api.disablekey=true' https://example.com

zap-cli quick-scan --self-contained --start-options '-config api.disablekey=true' https://example.com

Nikto:

nikto -h https://example.com -o nikto-report.html -Format html

nikto -h https://example.com -o nikto-report.html -Format html

6.2 Validación manual

Regla de oro: nunca confíes ciegamente en un escáner.

Los escáneres generan:

• Falsos positivos (dicen que hay vuln cuando no).
• Falsos negativos (no detectan vuln real).

Siempre:

• Reproduce la vulnerabilidad manualmente.
• Documenta con evidencias.
• Evalúa el impacto real.

6.3 Análisis de código (white box)

Si tienes acceso al código:

• SAST: análisis estático (Semgrep, SonarQube).
• DAST: análisis dinámico (Burp, ZAP).
• IAST: instrumentación (contrast security).
• SCA: dependencias (Snyk, Dependabot, Trivy).

# Semgrep - SAST
semgrep --config=auto /path/to/code

# Trivy - SCA
trivy fs /path/to/project

# Snyk - SCA
snyk test

# Semgrep - SAST
semgrep --config=auto /path/to/code

# Trivy - SCA
trivy fs /path/to/project

# Snyk - SCA
snyk test

Consulta nuestra Guía para asegurar APIs.

7. OWASP Top 10 en la práctica

A01: Broken Access Control

Qué es: usuarios acceden a recursos que no les corresponden.

Ejemplos:

• IDOR (Insecure Direct Object Reference).
• Escalada de privilegios.
• Bypass de autenticación.

Test:

# Cambiar IDs en URLs
https://example.com/user/123  →  https://example.com/user/124

# Modificar roles en peticiones
POST /api/user
{"role": "admin"}  →  {"role": "user"}

# Cambiar IDs en URLs
https://example.com/user/123  →  https://example.com/user/124

# Modificar roles en peticiones
POST /api/user
{"role": "admin"}  →  {"role": "user"}

Prevención:

• Validar accesos en servidor.
• Usar IDs no predecibles (UUID).
• Principio de mínimo privilegio.

A02: Cryptographic Failures

Qué es: uso incorrecto de criptografía.

Ejemplos:

• HTTP sin cifrado.
• Contraseñas sin hash (o MD5/SHA1).
• Certificados inválidos.

Test:

# Verificar HTTPS
testssl.sh example.com

# Ver versión TLS
openssl s_client -connect example.com:443 -tls1_2

# Verificar HTTPS
testssl.sh example.com

# Ver versión TLS
openssl s_client -connect example.com:443 -tls1_2

Prevención:

• HTTPS obligatorio.
• TLS 1.3.
• Hash con bcrypt/argon2.
• HSTS.

Consulta Cómo implementar HTTPS correctamente y Guía completa para configurar SSL en Nginx.

A03: Injection

Qué es: inyección de código (SQL, comandos, LDAP).

Ejemplos:

• SQL Injection.
• Command Injection.
• LDAP Injection.

Test:

# SQL Injection
sqlmap -u "https://example.com/?id=1" --dbs

# Command Injection
curl "https://example.com/?ip=127.0.0.1;whoami"

# SQL Injection
sqlmap -u "https://example.com/?id=1" --dbs

# Command Injection
curl "https://example.com/?ip=127.0.0.1;whoami"

Prevención:

• Prepared statements.
• Validación de entrada.
• WAF.

Consulta Seguridad en aplicaciones web: inyecciones SQL.

A04: Insecure Design

Qué es: fallos en el diseño de la aplicación.

Ejemplos:

• Recuperación de contraseña insegura.
• Falta de rate limiting.
• Flujos de negocio vulnerables.

Prevención:

• Threat modeling.
• Diseño seguro desde el inicio.
• Revisión de arquitectura.

A05: Security Misconfiguration

Qué es: configuraciones incorrectas.

Ejemplos:

• Cabeceras de seguridad ausentes.
• Debug habilitado.
• Directorios listados.
• Credenciales por defecto.

Test:

# Ver cabeceras
curl -I https://example.com

# Comprobar archivos sensibles
curl https://example.com/.env
curl https://example.com/wp-config.php.bak

# Ver cabeceras
curl -I https://example.com

# Comprobar archivos sensibles
curl https://example.com/.env
curl https://example.com/wp-config.php.bak

Prevención:

• Hardening de servidor.
• Cabeceras de seguridad.
• Eliminar archivos innecesarios.

Consulta Hardening de servidores web.

A06: Vulnerable and Outdated Components

Qué es: uso de componentes con vulnerabilidades conocidas.

Ejemplos:

• WordPress sin actualizar.
• jQuery antiguo.
• Librerías con CVEs.

Test:

# WPScan (WordPress)
wpscan --url https://example.com

# Trivy
trivy fs .

# WPScan (WordPress)
wpscan --url https://example.com

# Trivy
trivy fs .

Prevención:

• Actualizar regularmente.
• Monitorizar CVEs.
• Retirar componentes obsoletos.

A07: Identification and Authentication Failures

Qué es: autenticación débil.

Ejemplos:

• Contraseñas débiles.
• Sin MFA.
• Sesiones sin expiración.
• Credenciales por defecto.

Test:

bash

# Fuerza bruta con Hydra
hydra -l admin -P passwords.txt example.com http-post-form "/login:user=^USER^&pass=^PASS^:F=error"

# Burp Intruder para probar credenciales

# Fuerza bruta con Hydra
hydra -l admin -P passwords.txt example.com http-post-form "/login:user=^USER^&pass=^PASS^:F=error"

# Burp Intruder para probar credenciales

Prevención:

• MFA obligatorio.
• Políticas de contraseñas.
• Rate limiting.
• Bloqueo tras intentos fallidos.

Consulta Buenas prácticas en contraseñas y 2FA.

A08: Software and Data Integrity Failures

Qué es: falta de verificación de integridad.

Ejemplos:

• Actualizaciones sin firma.
• Dependencias inseguras.
• Deserialización insegura.

Prevención:

• Verificar firmas.
• SCA (software composition analysis).
• Validar integridad.

A09: Security Logging and Monitoring Failures

Qué es: falta de logs y monitorización.

Ejemplos:

• Sin logs de accesos.
• Sin alertas.
• Sin retención.

Prevención:

• Logs centralizados.
• SIEM.
• Alertas por eventos críticos.

Consulta Análisis de registros en Linux.

A10: Server-Side Request Forgery (SSRF)

Qué es: el servidor hace peticiones a recursos internos.

Ejemplos:

• Acceso a metadata cloud (169.254.169.254).
• Bypass de firewalls.
• Escaneo interno.

Test:

# Probar SSRF
curl "https://example.com/?url=http://169.254.169.254/latest/meta-data/"
curl "https://example.com/?url=file:///etc/passwd"

# Probar SSRF
curl "https://example.com/?url=http://169.254.169.254/latest/meta-data/"
curl "https://example.com/?url=file:///etc/passwd"

Prevención:

• Validar URLs.
• Lista blanca de dominios.
• Bloquear IPs internas.

8. Herramientas esenciales

8.1 Burp Suite

Estándar para pentesting web.

Componentes:

• Proxy: intercepta tráfico.
• Repeater: repite/modifica peticiones.
• Intruder: fuzzing.
• Scanner: escaneo automático (Pro).
• Decoder: codificación.

Configuración:

1. Instalar Burp.
2. Configurar proxy en navegador (127.0.0.1:8080).
3. Instalar CA de Burp.
4. Navegar la aplicación.

Extensiones útiles:

• Logger++
• Autorize
• Turbo Intruder
• Param Miner
• J2EEScan

8.2 OWASP ZAP

Alternativa open source a Burp.

# Instalación
sudo apt install zaproxy

# Escaneo rápido
zap-cli quick-scan --self-contained https://example.com

# Instalación
sudo apt install zaproxy

# Escaneo rápido
zap-cli quick-scan --self-contained https://example.com

Ventajas: CLI, API, integración CI/CD.

8.3 sqlmap

Explotación de SQL injection.

# Detección
sqlmap -u "https://example.com/?id=1"

# Enumerar bases de datos
sqlmap -u "https://example.com/?id=1" --dbs

# Enumerar tablas
sqlmap -u "https://example.com/?id=1" -D dbname --tables

# Dumpear datos
sqlmap -u "https://example.com/?id=1" -D dbname -T users --dump

# Con POST
sqlmap -u "https://example.com/login" --data="user=admin&pass=test" --dbs

# Con cookie
sqlmap -u "https://example.com/?id=1" --cookie="PHPSESSID=xxx"

# Shell
sqlmap -u "https://example.com/?id=1" --os-shell

# Detección
sqlmap -u "https://example.com/?id=1"

# Enumerar bases de datos
sqlmap -u "https://example.com/?id=1" --dbs

# Enumerar tablas
sqlmap -u "https://example.com/?id=1" -D dbname --tables

# Dumpear datos
sqlmap -u "https://example.com/?id=1" -D dbname -T users --dump

# Con POST
sqlmap -u "https://example.com/login" --data="user=admin&pass=test" --dbs

# Con cookie
sqlmap -u "https://example.com/?id=1" --cookie="PHPSESSID=xxx"

# Shell
sqlmap -u "https://example.com/?id=1" --os-shell

8.4 Nikto

Escáner de servidores web.

nikto -h https://example.com -o nikto-report.html -Format html

nikto -h https://example.com -o nikto-report.html -Format html

8.5 WPScan

Escáner específico de WordPress.

wpscan --url https://example.com --enumerate vp,vt,u

wpscan --url https://example.com --enumerate vp,vt,u

• vp: plugins vulnerables.
• vt: temas vulnerables.
• u: usuarios.

Consulta WordPress en Ubuntu Server 24.04 con Nginx.

8.6 Nuclei

Escáner moderno basado en templates.

nuclei -u https://example.com
nuclei -l urls.txt -t cves/
nuclei -u https://example.com -t exposures/

nuclei -u https://example.com
nuclei -l urls.txt -t cves/
nuclei -u https://example.com -t exposures/

8.7 testssl.sh

Análisis de SSL/TLS.

./testssl.sh https://example.com

./testssl.sh https://example.com

8.8 Gobuster / ffuf / Feroxbuster

Enumeración de directorios.

gobuster dir -u https://example.com -w wordlist.txt
ffuf -u https://example.com/FUZZ -w wordlist.txt
feroxbuster -u https://example.com -w wordlist.txt

gobuster dir -u https://example.com -w wordlist.txt
ffuf -u https://example.com/FUZZ -w wordlist.txt
feroxbuster -u https://example.com -w wordlist.txt

8.9 Subfinder / Amass

Enumeración de subdominios.

subfinder -d example.com
amass enum -d example.com

subfinder -d example.com
amass enum -d example.com

8.10 Semgrep / Snyk / Trivy

Análisis de código y dependencias.

semgrep --config=auto /path/to/code
snyk test
trivy fs /path/to/project

semgrep --config=auto /path/to/code
snyk test
trivy fs /path/to/project

Consulta Análisis de vulnerabilidades paso a paso.

9. Cómo redactar el informe

9.1 Estructura

1. Portada.
2. Resumen ejecutivo (sin tecnicismos).
3. Alcance y metodología.
4. Resumen de hallazgos.
5. Hallazgos detallados.
6. Conclusión.
7. Anexos (evidencias, comandos, logs).

9.2 Clasificación por severidad

9.3 Formato de hallazgo

ID: WEB-001
Título: SQL Injection en parámetro "id"
Criticidad: Crítica
CVSS: 9.8
CWE: CWE-89
OWASP: A03:2021 Injection
Ubicación: https://example.com/product?id=1

Descripción:
El parámetro "id" es vulnerable a SQL injection. Al inyectar 
comillas simples, se produce un error que revela la estructura 
de la base de datos.

Impacto:
Un atacante podría:
- Extraer toda la base de datos (usuarios, contraseñas).
- Modificar o borrar información.
- En algunos casos, ejecutar comandos en el servidor.

Evidencia:
Request:  POST /product?id=1' UNION SELECT 1,version(),database()-- 
Response: [captura con datos extraídos]

Remediación:
1. Usar prepared statements en todas las consultas.
2. Validar y sanitizar entrada del usuario.
3. Implementar WAF.
4. Aplicar principio de mínimo privilegio en la BD.

Referencias:
- OWASP A03:2021
- CWE-89
- https://owasp.org/Top10/A03_2021-Injection/

ID: WEB-001
Título: SQL Injection en parámetro "id"
Criticidad: Crítica
CVSS: 9.8
CWE: CWE-89
OWASP: A03:2021 Injection
Ubicación: https://example.com/product?id=1

Descripción:
El parámetro "id" es vulnerable a SQL injection. Al inyectar 
comillas simples, se produce un error que revela la estructura 
de la base de datos.

Impacto:
Un atacante podría:
- Extraer toda la base de datos (usuarios, contraseñas).
- Modificar o borrar información.
- En algunos casos, ejecutar comandos en el servidor.

Evidencia:
Request:  POST /product?id=1' UNION SELECT 1,version(),database()-- 
Response: [captura con datos extraídos]

Remediación:
1. Usar prepared statements en todas las consultas.
2. Validar y sanitizar entrada del usuario.
3. Implementar WAF.
4. Aplicar principio de mínimo privilegio en la BD.

Referencias:
- OWASP A03:2021
- CWE-89
- https://owasp.org/Top10/A03_2021-Injection/

9.4 Recomendaciones

• Concretas.
• Priorizadas.
• Cuantificadas (tiempo, coste).
• Accionables.

Consulta Cómo crear políticas de seguridad.

10. Checklist completo

10.1 Antes de la auditoría

• □ Contrato firmado.
• □ NDA firmado.
• □ RoE establecidas.
• □ Alcance definido.
• □ URLs/subdominios listados.
• □ Contactos identificados.
• □ Ventanas acordadas.

10.2 Reconocimiento

• □ Fingerprinting tecnologías.
• □ Enumeración de directorios.
• □ Enumeración de subdominios.
• □ Análisis de cabeceras.
• □ Análisis de robots.txt/sitemap.xml.
• □ OSINT sobre la organización.

10.3 Análisis de vulnerabilidades

• □ Escaneo automatizado (Burp/ZAP).
• □ Nikto en servidor web.
• □ Análisis SSL/TLS (testssl.sh).
• □ WPScan (si WordPress).
• □ Nuclei (CVEs).
• □ Análisis de dependencias (Snyk/Trivy).

10.4 OWASP Top 10

• □ A01: Broken Access Control.
• □ A02: Cryptographic Failures.
• □ A03: Injection.
• □ A04: Insecure Design.
• □ A05: Security Misconfiguration.
• □ A06: Vulnerable Components.
• □ A07: Authentication Failures.
• □ A08: Software/Data Integrity.
• □ A09: Logging Failures.
• □ A10: SSRF.

10.5 Reporte

• □ Resumen ejecutivo.
• □ Hallazgos clasificados.
• □ Evidencias (capturas, requests).
• □ Recomendaciones concretas.
• □ Referencias (OWASP, CWE, CVE).
• □ Revisado por segunda persona.

10.6 Post-auditoría

• □ Informe entregado.
• □ Presentación al cliente.
• □ Plan de remediación.
• □ Retesting programado.

11. Troubleshooting

11.1 «No puedo interceptar el tráfico»

Causas:

• Proxy mal configurado.
• Certificado CA no instalado.
• HSTS activo.

Solución:

• Configurar proxy en navegador.
• Instalar CA de Burp/ZAP.
• Deshabilitar HSTS temporalmente.

11.2 «El escáner bloquea la aplicación»

Causas:

• Escaneo demasiado agresivo.
• Rate limiting del servidor.

Solución:

• Reducir intensidad del escaneo.
• Añadir pausas.
• Coordinar con el cliente.

11.3 «Muchos falsos positivos»

Solución:

• Validar manualmente cada hallazgo.
• Combinar múltiples escáneres.
• Ajustar configuración del escáner.

11.4 «El WAF bloquea mis peticiones»

Causas:

• WAF activo (Cloudflare, ModSecurity).

Solución:

• Añadir IP del auditor a la whitelist.
• Coordinar con el cliente.
• Documentar la limitación.

11.5 «No encuentro vulnerabilidades»

Causas:

• Aplicación bien protegida.
• Falta de profundidad en el análisis.

Solución:

• Analizar lógica de negocio.
• Probar flujos completos.
• Revisar APIs y endpoints ocultos.

11.6 «El cliente no remedia»

Solución:

• Cuantificar el riesgo económico.
• Priorizar por criticidad.
• Incluir en el informe el impacto de no remediar.
• Ofrecer retesting.

11.7 «No sé si cumplo OWASP ASVS»

Solución:

• Usar el checklist de ASVS L1/L2/L3.
• Documentar cada punto.
• Certificaciones útiles: OSWE, GWAPT.

12. FAQ

¿Qué es una auditoría de seguridad web?

Es un proceso sistemático y documentado que evalúa la seguridad de una aplicación web en todas sus capas: código, infraestructura, configuración, procesos y personas.

Objetivos: identificar vulnerabilidades, evaluar riesgos, recomendar mitigaciones.

¿Cuál es la diferencia entre auditoría y pentesting web?

• Auditoría: evaluación completa (técnica + infra + procesos).
• Pentesting: simulación de ataque técnico.

La auditoría incluye pentesting cuando es necesario.

Consulta Guía Completa de Hacking Ético.

¿Cada cuánto tiempo debo auditar mi web?

Recomendación general:

• Sitios críticos: cada 6 meses.
• E-commerce: cada 3-6 meses (PCI-DSS).
• Sitios informativos: cada 1-2 años.
• Tras cambios importantes: siempre.

¿Cuánto cuesta una auditoría web?

Varía según alcance:

Factores: tamaño, tecnologías, profundidad, certificaciones.

¿Qué herramientas necesito?

Esenciales:

• Burp Suite (estándar).
• OWASP ZAP (alternativa open source).
• sqlmap (SQL injection).
• Nikto (servidor web).
• Nuclei (CVEs).
• Gobuster/ffuf (directorios).
• testssl.sh (SSL/TLS).

Todas son gratuitas (excepto Burp Pro).

¿Es legal auditar una web?

Sí, con autorización por escrito:

• Contrato con alcance definido.
• NDA firmado.
• RoE claras.
• Contacto técnico.

Sin autorización es delito. Consulta Guía Completa de Hacking Ético.

¿Qué es OWASP Top 10?

Lista de las 10 vulnerabilidades web más críticas:

A01: Broken Access Control.
A02: Cryptographic Failures.
A03: Injection.
A04: Insecure Design.
A05: Security Misconfiguration.
A06: Vulnerable Components.
A07: Authentication Failures.
A08: Software/Data Integrity.
A09: Logging Failures.
A10: SSRF.

Uso: como checklist en auditorías.

¿Cómo protejo mi web contra las vulnerabilidades OWASP?

Estrategia:

1. Hardening del servidor (ver guía).
2. HTTPS obligatorio.
3. Validación de entrada estricta.
4. Autenticación fuerte (MFA).
5. WAF (Cloudflare, ModSecurity).
6. Actualizaciones regulares.
7. Logs y monitorización.
8. Backups regulares.

Consulta Hardening de servidores web y Guía de seguridad en la nube.

¿Qué incluye el informe de auditoría web?

Estructura típica:

1. Resumen ejecutivo.
2. Alcance y metodología.
3. Hallazgos clasificados por severidad.
4. PoC por hallazgo.
5. Recomendaciones.
6. Anexos con evidencias.

Consulta nuestra Guía de auditoría de ciberseguridad.

¿Necesito ser un experto para auditar mi web?

No, pero necesitas:

• Conocimientos de seguridad web.
• Herramientas adecuadas.
• Metodología clara.
• Paciencia.

Alternativas:

• Auditoría externa (más completa).
• Bug bounty (pago por hallazgo).
• Escáneres automáticos (básicos).

¿Cómo puedo prevenir vulnerabilidades web?

Buenas prácticas:

• Formación del equipo.
• Code reviews con seguridad.
• SAST/DAST en CI/CD.
• WAF activo.
• Actualizaciones regulares.
• Pentesting periódico.
• Backups y plan de respuesta.

Consulta Seguridad en CI/CD.

¿Qué es el OWASP ASVS?

Application Security Verification Standard. Define 3 niveles de requisitos de seguridad:

• L1: básico (todas las apps).
• L2: defensivo (datos sensibles).
• L3: avanzado (apps críticas).

Uso: como estándar de referencia para auditorías.

13. Conclusión

Una auditoría de seguridad web es un proceso esencial para cualquier negocio con presencia online. No se trata solo de encontrar vulnerabilidades, sino de entender el riesgo real y recomendar soluciones concretas.

Puntos clave:

1. Definir bien el alcance y objetivos.
2. Seguir OWASP (Top 10, ASVS, WSTG).
3. Combinar automatización + validación manual.
4. Cubrir todas las capas: código, infra, configuración.
5. Usar herramientas adecuadas (Burp, ZAP, sqlmap).
6. Redactar informe claro y accionable.
7. Priorizar remediaciones por riesgo real.
8. Re-auditar periódicamente.
9. Formar al equipo continuamente.
10. Cumplir con normativas aplicables.

Si quieres profundizar:

• Guía Completa de Ciberseguridad 2026
• Guía Completa de Hacking Ético 2026
• Auditoría de ciberseguridad paso a paso
• Análisis de vulnerabilidades paso a paso
• Pruebas de penetración en aplicaciones web
• Seguridad en aplicaciones web: inyecciones SQL
• Cómo asegurar APIs
• Hardening de servidores web
• Cómo implementar HTTPS correctamente
• Guía completa para configurar SSL en Nginx
• Seguridad en CI/CD