Cómo añadir security.txt en 5 minutos — inicio para la divulgación de vulnerabilidades | Scanthra

Scanthra · 6 min de lectura · Actualizado Mayo de 2026

Qué es realmente security.txt

security.txt es un pequeño archivo de texto plano legible por máquina que publicas en tu sitio web. Es el equivalente del mundo de la seguridad al robots.txt: una ubicación conocida, una sintaxis simple y un propósito claro. Su función es responder una pregunta para alguien que cree haber encontrado una vulnerabilidad en tu sitio — «¿a quién se lo digo, y cómo?»

El formato está estandarizado en IETF RFC 9116 («A File Format to Aid in Security Vulnerability Disclosure»). Se convirtió en Estándar Propuesto en 2022, así que ya no es un borrador ni una rareza — es la forma acordada de hacer esto.

Por qué importa aunque no seas un banco

Tres razones por las que vale la pena los cinco minutos:

• Los investigadores pueden contactarte. Sin un canal claro, los descubridores bien intencionados o desisten, publican el problema públicamente o envían correos al azar a tu formulario de contacto genérico. Una dirección documentada captura el problema pronto, de forma privada.
• Los procesos de compra y los cuestionarios lo esperan. Los cuestionarios de seguridad para proveedores (SIG, CAIQ y los personalizados de empresas) y las listas de verificación con la forma de NIS2 (directiva UE de ciberseguridad) preguntan cada vez más «¿publicas una política de divulgación de vulnerabilidades?». Un security.txt activo es el «sí» más barato posible.
• Señala madurez. Un sitio con un security.txt vigente parece uno cuyo propietario ha pensado en qué pasa cuando algo va mal. Eso solo ya te saca del cuartil inferior.

Los campos que define el RFC 9116

Solo Contact y Expires son obligatorios. El resto es opcional pero útil.

• Contact: — obligatorio. Una o más formas de contactarte: un correo electrónico (con el prefijo mailto:), un número de teléfono (tel:), o una URL de reporte (https://). Se permiten varias líneas Contact; listarlas en orden de preferencia.
• Expires: — obligatorio. Una marca de tiempo ISO 8601 después de la cual este archivo ya no debería ser de confianza. La mayoría de los equipos la fijan 6–12 meses en el futuro y la actualizan con un recordatorio de calendario.
• Encryption: — una URL a tu clave pública PGP, si quieres reportes cifrados. Opcional pero apreciado.
• Acknowledgments: — una URL a una página que agradece a los investigadores que han reportado problemas responsablemente. Buena reputación barata.
• Preferred-Languages: — etiquetas de idioma BCP 47 separadas por comas (RFC 5646) (por ejemplo es, en). Puedes omitirlo — la mayoría de los equipos entienden el inglés más su propio idioma.
• Canonical: — la URL canónica de este archivo. Útil si tu sitio es accesible en varios nombres de host; indica a los parsers cuál es la copia autorizada.
• Policy: — una URL a tu política completa de divulgación de vulnerabilidades: ámbito, lenguaje de puerto seguro, tiempo de respuesta esperado.
• Hiring: — una URL a tu página de empleos del equipo de seguridad. Sí, está en la especificación.
• CSAF: — una URL a un archivo de metadatos del proveedor CSAF 2.0. Solo relevante si publicas avisos legibles por máquina; las pequeñas empresas pueden ignorarlo.

Una plantilla lista para usar

Reemplaza el correo electrónico, las fechas y las URLs con los tuyos. Mantén el archivo en ASCII simple (sin BOM) y usa finales de línea UNIX. Las líneas que empiezan con # son comentarios.

# security.txt for example.com
# Please report security issues using the contacts below.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-05-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

Dónde colocarlo

La ubicación canónica es:

https://tudominio.com/.well-known/security.txt

La ubicación heredada /security.txt en la raíz del documento también es tolerada por la mayoría de las herramientas, pero la ruta /.well-known/ es la que prescribe el RFC 9116 — usa esa.

nginx

location = /.well-known/security.txt {
    alias /var/www/example.com/.well-known/security.txt;
    default_type text/plain;
    add_header Cache-Control "public, max-age=3600";
}

Apache

<Files "security.txt">
    ForceType text/plain
    Header set Cache-Control "public, max-age=3600"
</Files>

Solo coloca el archivo en /var/www/example.com/.well-known/security.txt y asegúrate de que Apache tiene permiso para servir directorios ocultos (algunas configuraciones predeterminadas bloquean las rutas con prefijo .).

Hosts estáticos, WordPress, Cloudflare Pages, Vercel, Netlify

Coloca un archivo llamado security.txt en una carpeta llamada .well-known en el directorio de activos públicos y vuelve a desplegar. La mayoría de los hosts estáticos sirven directorios con punto sin problema; compruébalo visitando la URL justo después del despliegue.

Fírmalo (opcional pero elegante)

El RFC 9116 permite que el archivo sea un mensaje PGP firmado en claro. La mayoría de las pequeñas empresas no se molestan — y está bien. Si ya publicas una clave PGP, firmar dificulta que alguien falsifique el archivo mediante un host comprometido. Si no, omítelo; un archivo sin firmar es perfectamente válido.

Errores habituales que vale la pena evitar

• Expires ausente. Una línea Expires caducada o ausente hace que el archivo sea inválido según la especificación. Los parsers advertirán o lo rechazarán.
• Tipo MIME incorrecto. El archivo debe servirse como text/plain; a veces un servidor web devuelve application/octet-stream y rompe el parsing.
• Solo HTTPS. security.txt debe servirse por HTTPS en su URL canónica. Una versión HTTP simple es ignorada.
• Bandeja de entrada personal en Contact. Usa una dirección de rol como security@ que sobreviva a los cambios de personal, no juan@.
• Renovación olvidada. Pon la fecha de Expires en el mismo calendario donde renuevas los certificados TLS. Un security.txt caducado es peor que ninguno — le dice a los investigadores que el equipo está dormido.

Cómo Scanthra detecta esto

Nuestro módulo M10 de robots y well-known comprueba si /.well-known/security.txt existe y es accesible en la URL HTTPS canónica. Si falta, mostramos una observación de gravedad baja en lugar de un problema — es un «bueno tenerlo, no una herida» — e incluimos esta guía como solución sugerida. Los sitios que ya publican un archivo válido reciben un reconocimiento discreto en el mapa de cumplimiento.