El problema: tu sitio puede estar expuesto sin que lo sepas
Un sitio web no es solo lo que se ve. Detrás de cada página hay archivos, configuraciones, claves y dependencias que, si no se revisan, se convierten en puertas abiertas. El problema no es que los atacantes sean genios: es que los desarrolladores dejan rastros sin querer.
El escenario típico: un desarrollador subió un archivo .env con las claves de la API de pagos, un backup de la base de datos quedó en la carpeta pública, o una dependencia de npm tiene una vulnerabilidad conocida que nadie actualizó. Nada de esto es visible para el usuario, pero sí para cualquiera que sepa dónde mirar.
La higiene web no es un tema de seguridad avanzada. Es el equivalente a cerrar las puertas y ventanas antes de irte de viaje. Y la mayoría de los sitios no lo hace.
Lo que los atacantes buscan primero
Los atacantes no empiezan por el código fuente. Empiezan por lo que está expuesto en el servidor. Estas son las cinco cosas que más se encuentran en sitios chilenos:
1. Claves API en el frontend
Las claves de Stripe, AWS, Google Maps o cualquier servicio externo que se incluyan en el JavaScript del frontend son visibles para cualquiera que abra las herramientas de desarrollador. No es un secreto: es público.
2. Archivos sensibles en la carpeta pública
Archivos .env, .git, backups de base de datos, archivos de configuración. Si están en la carpeta pública del servidor, cualquiera puede descargarlos.
3. Dependencias con vulnerabilidades conocidas
Cada dependencia de npm, pip o composer es una puerta potencial. Si no se actualizan, las vulnerabilidades conocidas (CVEs) se acumulan y los atacantes las explotan automáticamente.
4. Headers de seguridad faltantes
Sin Content-Security-Policy, X-Frame-Options o Strict-Transport-Security, el navegador no tiene instrucciones para proteger al usuario de ataques de inyección o clickjacking.
5. Configuraciones por defecto
Puertos abiertos, paneles de administración sin autenticación, servicios de debug activos. Todo lo que vino "por defecto" y nadie cambió.
El estándar de referencia: OWASP Web Security Testing Guide
El OWASP Web Security Testing Guide (WSTG) es el recurso de referencia para pruebas de seguridad en aplicaciones web, producido por la OWASP Foundation. La versión actual es la 4.2, con la versión 5.0 en desarrollo. Es un proyecto Flagship de OWASP, con licencia Creative Commons Attribution Share Alike 4.0 (fuente primaria: https://owasp.org/projects/web-security-testing-guide).
El WSTG cubre todo el ciclo de pruebas: desde la recolección de información hasta la explotación de vulnerabilidades. No es un checklist de 10 puntos: es un framework completo para evaluar la seguridad de una aplicación web.
Para la higiene web, los puntos relevantes son:
- Information Gathering: qué expone tu sitio (archivos, directorios, configuraciones).
- Configuration and Deployment Management Testing: headers, puertos, servicios.
- Identity Management Testing: autenticación, sesiones, credenciales.
- Input Validation Testing: inyección, XSS, CSRF.
- Error Handling: qué información revelan los errores.
Checklist de 12 puntos para higiene web
1. Revisa los archivos públicos
Busca en la carpeta pública de tu servidor: .env, .git, config.php, wp-config.php, backups (*.sql, *.zip, *.bak). Si están ahí, muévelos o elimínalos.
2. Verifica las claves API
Abre las herramientas de desarrollador de tu navegador y busca en el JavaScript del frontend. Si encuentras claves de servicios externos, muévelas al backend.
3. Actualiza las dependencias
Ejecuta npm audit, pip check o el equivalente de tu stack. Revisa las vulnerabilidades críticas y actualiza. Si no puedes actualizar, documenta por qué.
4. Configura los headers de seguridad
Agrega al menos: Content-Security-Policy, X-Frame-Options: DENY, Strict-Transport-Security, X-Content-Type-Options: nosniff. Cada uno cierra una puerta específica.
5. Cierra los puertos innecesarios
Revisa qué puertos están abiertos en tu servidor. Si no necesitas el puerto 22 (SSH) expuesto a internet, ciérralo o restringe el acceso por IP.
6. Desactiva el debug en producción
Los modos de debug revelan información interna del sistema: rutas, variables, errores detallados. Desactívalos en producción.
7. Protege los paneles de administración
Si tienes un panel de admin, asegúrate de que esté protegido con autenticación fuerte y, si es posible, restringido por IP.
8. Revisa los certificados SSL
Verifica que tu certificado SSL esté vigente, que use TLS 1.2 o superior, y que no haya errores de configuración.
9. Limpia los backups
Los backups antiguos son un riesgo. Si no los necesitas, elimínalos. Si los necesitas, muévelos fuera de la carpeta pública.
10. Revisa los permisos de archivos
Los archivos no deberían ser escribibles por todos. Revisa los permisos: 644 para archivos, 755 para directorios.
11. Monitorea los cambios
Configura alertas para cambios en archivos críticos. Si alguien modifica un archivo de configuración, deberías saberlo.
12. Documenta lo que hiciste
La higiene web no es un evento único. Documenta qué revisaste, qué corregiste y qué quedó pendiente. La próxima revisión será más fácil.
Lo que la higiene web no resuelve
La higiene web cubre la superficie: lo que está expuesto y lo que está mal configurado. No cubre:
- Vulnerabilidades en el código. Un SQL injection no se detecta con un checklist de archivos. Para eso necesitas pentesting.
- Ataques de ingeniería social. Un empleado que da su contraseña no es un problema de higiene web.
- Amenazas internas. Un usuario con acceso legítimo que actúa maliciosamente no se detecta con headers de seguridad.
La higiene web es el primer paso, no el último.
Nota sobre fuentes
Las afirmaciones técnicas de este artículo se basan en el OWASP Web Security Testing Guide (https://owasp.org/projects/web-security-testing-guide), proyecto Flagship de OWASP, versión 4.2. No se incluyen cifras de incidencia de vulnerabilidades, porque no se pudo verificar un estudio primario que las respalde.
Próximo paso
Si tu equipo nunca ha hecho una revisión de higiene web, el siguiente paso no es contratar un pentest: es empezar por el checklist.
- Habla con el equipo: revisamos tu sitio y te decimos qué está expuesto.
- Crea tu cuenta: parte con el diagnóstico de tu infraestructura.
- Conoce NPM Secure: si usas dependencias de npm, revisa si tienen vulnerabilidades conocidas.