Un escáner gratuito que verifica el certificado SSL y los encabezados HTTP da una falsa impresión de cobertura. El OWASP Top 10:2025 coloca la Configuración de Seguridad en segundo lugar e introduce las Fallas en la Cadena de Suministro de Software como una categoría independiente. Probar la seguridad de un sitio web en línea supone entender lo que estas herramientas realmente captan, y sobre todo lo que ignoran.
Cadena de Suministro y condiciones excepcionales: los puntos ciegos de los escáneres gratuitos
La mayoría de las herramientas accesibles sin registro analizan la superficie expuesta: validez del certificado TLS, presencia de los encabezados Content-Security-Policy, X-Frame-Options, configuración DNS. Es una base útil, pero que no cubre ni la cadena de dependencias de software ni la gestión de errores de aplicación.
El OWASP Top 10:2025 ha formalizado estos dos riesgos bajo las categorías Fallas en la Cadena de Suministro de Software y Manejo Incorrecto de Condiciones Excepcionales. Un componente JavaScript importado a través de npm, una imagen Docker construida sobre una base no mantenida, un pipeline CI/CD cuyos secretos están expuestos: ningún escaneo externo anónimo detecta estos defectos.
Recomendamos tratar el escaneo en línea como un primer filtro, no como una auditoría. Identifica los errores de configuración visibles desde el exterior. Para la cadena de software, se necesita una herramienta de tipo Análisis de Composición de Software (Snyk Open Source, OWASP Dependency-Check) ejecutada en el repositorio de código.
Antes de lanzar un escaneo, es útil probar la seguridad de un sitio web en línea entendiendo precisamente el alcance cubierto por cada herramienta, para evitar confundir un informe limpio con una superficie de ataque realmente reducida.
Configuración de Seguridad: lo que realmente detectan los escaneos de encabezados HTTP
El ascenso de la Configuración de Seguridad al segundo lugar en el ranking de OWASP no es anecdótico. Refleja la multiplicación de las superficies de configuración: buckets de nube públicos, endpoints de administración accesibles, páginas de error verbosas que exponen trazas de pila, cookies sin el atributo Secure o SameSite.
Los escáneres gratuitos cubren una parte de este alcance. Verifican típicamente:
- La presencia y el valor de los encabezados de seguridad HTTP (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- La configuración TLS (versión del protocolo, suites de cifrado, expiración del certificado)
- La exposición de información del servidor en los encabezados de respuesta (Server, X-Powered-By)
- La política CORS y los orígenes permitidos
Sin embargo, un escaneo externo no prueba las configuraciones internas: reglas IAM de un bucket S3, acceso a una consola de administración protegida por una URL oscura, o variables de entorno inyectadas en texto claro en el código fuente del lado del cliente. Estas verificaciones requieren acceso autenticado o una auditoría del código desplegado.
Interpretar un puntaje de seguridad sin sobrevalorar
Un informe que muestra un puntaje alto (A o A+) en los encabezados HTTP no significa que la aplicación sea segura. Significa que la capa de transporte y las directrices del navegador están correctamente configuradas. Observamos regularmente sitios calificados como A+ cuyo panel de administración es accesible a través de /admin sin restricción de IP ni doble autenticación.
El puntaje es un indicador de madurez sobre un alcance preciso. No cubre ni la lógica de negocio ni los controles de acceso de la aplicación.
Control de Acceso Roto y pruebas autenticadas: el límite estructural del escaneo anónimo
El riesgo clasificado número uno por OWASP en 2025 sigue siendo el Control de Acceso Roto, que ahora incluye el SSRF (Server-Side Request Forgery). Este tipo de vulnerabilidad requiere cuentas de prueba con varios niveles de privilegios y escenarios de negocio concretos: un usuario estándar que intenta acceder a un recurso reservado para un administrador, una solicitud API que modifica el identificador de un objeto para alcanzar los datos de otro usuario (IDOR).
Ningún escáner externo anónimo puede validar los controles de acceso sin tener al menos dos sesiones autenticadas con roles diferentes. Una herramienta como OWASP ZAP permite configurar contextos de autenticación y reproducir escenarios, pero esto excede el marco de una simple prueba en línea.
Enfoque combinado para una auditoría realista sin presupuesto
Para cubrir un alcance aceptable sin inversión financiera, recomendamos combinar tres capas:
- Un escaneo de encabezados y configuración TLS a través de una herramienta en línea gratuita (Mozilla Observatory, SecurityHeaders.com) para el alcance de red y transporte
- Un proxy de interceptación local (OWASP ZAP en modo estándar) para probar manualmente los controles de acceso y las inyecciones en los formularios, con sesiones autenticadas
- Un análisis de dependencias (npm audit, pip-audit, OWASP Dependency-Check) directamente en el pipeline de construcción para cubrir la cadena de software
Esta combinación cubre tres de los cinco principales riesgos del ranking OWASP 2025. No reemplaza una prueba profesional, pero eleva significativamente el nivel de detección en comparación con un escaneo único de encabezados HTTP.
CORS, cookies y Content-Security-Policy: los ajustes a verificar prioritariamente
Entre los elementos que se pueden probar gratuitamente, tres configuraciones concentran una parte desproporcionada de los errores explotables.
La política CORS mal configurada sigue siendo frecuente. Un Access-Control-Allow-Origin configurado en * con Access-Control-Allow-Credentials en true expone las cookies de sesión a cualquier dominio externo. Los escáneres gratuitos señalan esta combinación, pero no prueban las consecuencias aplicativas.
Los atributos de las cookies merecen una atención especial. Una cookie de sesión sin Secure, sin HttpOnly y sin SameSite=Strict (o Lax) es vulnerable al robo a través de XSS o a la inclusión en solicitudes cross-site. Los navegadores recientes mitigan algunos escenarios, pero la configuración explícita sigue siendo la única protección confiable del lado del servidor.
Finalmente, una Content-Security-Policy permisiva anula la protección contra las inyecciones XSS. Una directiva script-src que contenga ‘unsafe-inline’ o ‘unsafe-eval’ convierte la CSP en algo cosmético. Las herramientas de escaneo en línea detectan estas directivas, lo que las convierte en uno de los pocos controles aplicativos accesibles sin autenticación.
La gratuidad de una herramienta de prueba no plantea un problema en sí misma. Lo que crea una falsa sensación de seguridad es tratar el informe como exhaustivo cuando solo cubre una fracción de la superficie de ataque real. Un escaneo limpio de los encabezados HTTP sigue siendo un buen punto de partida, siempre que se continúe con las capas que la herramienta no puede alcanzar.
