Configuraciones de Seguridad Inseguras
Qué es la Configuración de Seguridad Inadecuada
La configuración de seguridad inadecuada (A05:2021 en el OWASP Top 10) abarca todos los fallos que surgen no del código de la aplicación, sino de cómo está configurada la plataforma que la rodea: el servidor web, el framework, la base de datos, el contenedor, el proveedor de nube. Es una de las categorías más comunes porque hay muchísimas piezas que configurar y cualquier valor por defecto inseguro o ajuste olvidado abre una puerta.
A diferencia de la inyección o el XSS, que dependen de un fallo concreto en una línea de código, la mala configuración es transversal y a menudo invisible hasta que alguien la encuentra. Ejemplos típicos: cuentas por defecto con contraseñas conocidas, funciones de depuración activas en producción, permisos de archivos demasiado abiertos, servicios innecesarios expuestos y mensajes de error que revelan detalles internos del sistema.
Cabeceras de Seguridad HTTP
Los navegadores modernos ofrecen muchos mecanismos de protección que solo se activan si el servidor envía las cabeceras de seguridad adecuadas. Omitirlas es una forma frecuente de configuración insegura. La cabecera Content-Security-Policy (CSP), que vimos en la lección de XSS, controla desde dónde puede cargar recursos la página y es una de las defensas más potentes contra la inyección de scripts.
La cabecera Strict-Transport-Security (HSTS) obliga al navegador a usar siempre HTTPS, evitando ataques de degradación a HTTP. X-Content-Type-Options: nosniff impide que el navegador interprete archivos con un tipo distinto al declarado. X-Frame-Options o la directiva frame-ancestors de CSP protegen contra el clickjacking impidiendo que tu sitio se embeba en un iframe malicioso. Y Referrer-Policy controla cuánta información de la URL se filtra al navegar a otros sitios. Configurar estas cabeceras es de bajo costo y alto impacto.
Exposición de Datos Sensibles
Una mala configuración suele traducirse en exposición de datos sensibles. Los casos más comunes incluyen listados de directorios habilitados que muestran la estructura de archivos del servidor, archivos de respaldo o .git accesibles públicamente, mensajes de error detallados que revelan rutas, versiones de software o fragmentos de consultas, y endpoints de administración o métricas expuestos sin autenticación.
Otro patrón crítico es transmitir o almacenar datos sensibles sin la protección adecuada: tráfico sin HTTPS, contraseñas con hashing débil (relacionado con A02:2021 — Cryptographic Failures), o información personal devuelta en respuestas de API que no la necesitan. La regla práctica es minimizar: no recolectes, no almacenes y no devuelvas datos sensibles que no sean estrictamente necesarios, y cuando lo hagas, protégelos en tránsito y en reposo.
Manejo Seguro de Secretos
Los secretos (claves de API, contraseñas de base de datos, tokens de servicios, claves de cifrado) son uno de los activos más peligrosos de gestionar mal. Un error clásico y muy frecuente es incrustar secretos en el código fuente y subirlos a un repositorio. Una vez que un secreto entra en el historial de Git, eliminarlo del último commit no basta: queda en el historial y debe considerarse comprometido y rotado.
La práctica correcta es mantener los secretos fuera del código: en variables de entorno, en archivos de configuración no versionados, o idealmente en un gestor de secretos dedicado (como Vault o los servicios de secretos de los proveedores de nube). Usa archivos .gitignore para evitar subir configuraciones sensibles, escanea tus repositorios con herramientas de detección de secretos, y establece la rotación periódica de credenciales. Trata cada secreto como si su exposición fuera inevitable algún día: minimiza su alcance y prepara su rotación.
Endurecimiento y Verificación
El hardening (endurecimiento) es el proceso de reducir la superficie de ataque de un sistema configurándolo de forma segura. Empieza por desactivar todo lo que no necesitas: módulos, servicios, puertos, cuentas y funciones de ejemplo. Cambia todas las credenciales por defecto. Mantén el software actualizado y aplica los parches de seguridad con prontitud, ya que muchas configuraciones inseguras provienen de versiones obsoletas.
Adopta una configuración repetible y auditable: define entornos idénticos mediante infraestructura como código, de modo que la configuración segura se aplique de forma consistente en desarrollo, pruebas y producción, sin desviaciones manuales. Verifica tu postura con escáneres de configuración, análisis automatizados con OWASP ZAP y revisiones periódicas frente a guías como los CIS Benchmarks. Como la configuración cambia con el tiempo, conviértela en parte de tu monitoreo continuo en lugar de una tarea que se hace una vez y se olvida.