Parte 5 de la serie "Seguridad web en la UE: 10 pasos para una mejor calificación"
Por qué security.txt
Un investigador de seguridad encuentra una vulnerabilidad en tu sitio web. ¿A quién contacta?
Sin security.txt: Busca en tu sitio, encuentra info@, envía un correo electrónico. Llega a marketing, se borra como spam o se ignora. La vulnerabilidad permanece abierta.
Con security.txt: Visita /.well-known/security.txt, encuentra el contacto de seguridad, la clave PGP y la política de divulgación. El informe llega al equipo adecuado de inmediato.
Tasa de adopción en la UE: 2,8%. Y sin embargo: los sitios web con security.txt puntúan un 31% más alto de media que los que no lo tienen.
La correlación
| Métrica | CON security.txt | SIN | Factor |
|---|---|---|---|
| Puntuación compuesta | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8x |
| CSP | 47% | 10% | 4,7x |
| Calificación F | 6% | 44% | 7x menos |
security.txt no es una solución mágica. Pero quienes se toman el tiempo de configurarlo normalmente se han ocupado de todo lo demás.
Cómo configurar security.txt
Paso 1: Crear el archivo
Crea /.well-known/security.txt en tu servidor web:
Contact: mailto:security@tu-dominio.com
Expires: 2027-04-13T00:00:00.000Z
Preferred-Languages: es
Campos obligatorios (RFC 9116):
- Contact: — dirección de correo o URL para informes de seguridad
- Expires: — fecha de expiración (máximo 1 año en el futuro)
Campos opcionales:
- Encryption: — clave PGP para informes cifrados
- Acknowledgments: — hall de la fama para reporteros responsables
- Canonical: — URL canónica del archivo
- Policy: — enlace a tu Política de Divulgación de Vulnerabilidades
- Hiring: — enlace a ofertas de empleo en seguridad
Paso 2: Hacerlo accesible
El archivo debe ser accesible en https://tu-dominio.com/.well-known/security.txt. Para la mayoría de las configuraciones:
Nginx:
location = /.well-known/security.txt {
alias /var/www/tu-dominio.com/security.txt;
}
Apache: Simplemente coloca el archivo en /.well-known/ en la raíz del documento.
WordPress: Usa el plugin "WP Security.txt" o colócalo manualmente en .well-known/ en la raíz del sitio.
Paso 3: Proporcionar una clave PGP (recomendado)
Contact: mailto:security@tu-dominio.com
Encryption: https://tu-dominio.com/.well-known/pgp-key.txt
Expires: 2027-04-13T00:00:00.000Z
ENISA recomienda la opción de cifrado para que los investigadores de seguridad puedan enviar detalles sensibles de forma protegida.
Adopción por sector
| Sector | Adopción | Puntuación media con | Puntuación media sin |
|---|---|---|---|
| Banca | 23,9% | 69 | 55 |
| Comercio electrónico | 15,6% | 64 | 53 |
| Educación | 8,1% | 53 | 42 |
| Tecnología | 5,3% | 63 | 45 |
| Sanidad | 2,0% | 58 | 42 |
| Hostelería | 1,1% | 51 | 40 |
La banca lidera — casi uno de cada cuatro bancos tiene security.txt. La hostelería (hoteles, restaurantes) está en el 1,1%.
Contexto regulatorio
- NIS2 Art. 21(2)(e) exige explícitamente "gestión y divulgación de vulnerabilidades" — security.txt es el mecanismo estandarizado para ello
- CRA Art. 14 — la divulgación coordinada de vulnerabilidades será obligatoria desde diciembre de 2027 para fabricantes de productos digitales
- ENISA incluye security.txt como buena práctica para la divulgación de vulnerabilidades
- CERT nacionales de toda Europa (CCN-CERT en España, INCIBE, ANSSI, BSI) recomiendan o usan security.txt en sus propios dominios
Errores comunes
1. Olvidar Expires. Sin Expires, el archivo no es válido según el RFC 9116. Configúralo a 1 año en el futuro y pon un recordatorio para actualizarlo.
2. HTTP en vez de HTTPS. El archivo debe servirse por HTTPS — un security.txt sin cifrar podría ser manipulado.
3. info@ como contacto. Contact: mailto:info@... llega a marketing. Configura una dirección security@ dedicada que llegue a una persona responsable de seguridad.
Comprueba tu security.txt
La próxima semana en la Parte 6: DKIM — por qué solo el 31% de los dominios de la UE firma sus correos electrónicos.