Generador y verificador de security.txt
Crea un security.txt válido según la RFC 9116 para que los investigadores sepan cómo contactarte, o pega uno existente para ver qué falla. Forma parte de la preparación para el Reglamento de Ciberresiliencia de la UE (CRA).
Funciona completamente en tu navegador
Genera un security.txt
Verifica un security.txt
Solo comprueba el texto según la RFC 9116. No consulta tu sitio web (nada de lo que escribes sale de esta página, por eso debes pegar el archivo), no verifica una firma OpenPGP ni prueba que una dirección funcione. Es una plantilla, no asesoría legal.
Cómo crear y verificar un security.txt
- Escribe al menos un Contact (una dirección de correo, un número de teléfono o una página https://) y revisa la fecha de Expires. Completa los campos opcionales que quieras, como Policy y Preferred-Languages.
- Copia el archivo o descárgalo, y publícalo en
/.well-known/security.txtde tu dominio, por HTTPS y como texto plano. - Para verificar un archivo existente, pega su texto en el verificador. Corrige los errores y luego revisa las advertencias. Agrega la dirección desde la que lo publicas para comprobar el campo Canonical.
- Pon un recordatorio en tu calendario para renovar Expires antes de que venza.
Para qué sirve un security.txt
Cuando un investigador, un cliente o un CERT encuentra una debilidad en tu software, el primer problema es a quién avisar. Un security.txt es un pequeño archivo de texto en una dirección fija, /.well-known/security.txt, que lo resuelve: un contacto, una fecha de vencimiento y, opcionalmente, un enlace a tu política de divulgación y una clave pública. La RFC 9116 define el formato, y muchos escáneres, plataformas de bug bounty y CERT nacionales buscan este archivo antes que cualquier otra cosa.
Para un proveedor de software de la UE también ayuda a cumplir obligaciones del Reglamento de Ciberresiliencia: el anexo I espera que exista una vía publicada para que terceros informen de vulnerabilidades y un proceso para gestionarlas. El reglamento no menciona este formato, pero es la forma habitual de publicar el contacto. La guía de notificación para pequeños proveedores explica el resto de la preparación, incluido el plazo de 24 horas.
Los campos
Contact y Expires son obligatorios. Contact puede aparecer varias veces y debe ser un URI: mailto:, tel: o https:. Expires aparece una sola vez, como fecha y hora del estilo 2027-12-31T23:59:59Z, y la RFC 9116 pide que sea dentro de menos de un año. Encryption, Acknowledgments, Policy, Hiring y Canonical son enlaces opcionales, y toda dirección web debe usar https. Preferred-Languages aparece una sola vez y enumera códigos de idioma. Los lectores ignoran los campos que la RFC no define, por eso el verificador los marca como advertencias: casi siempre son errores de escritura.
Consejos
- Usa un buzón que lean varias personas, no la dirección de una sola, y pruébalo escribiéndole.
- Redacta una política de divulgación de vulnerabilidades y enlázala con el campo Policy.
- Conoce tus plazos antes de que llegue un informe: el reloj de 24 horas del CRA convierte el momento en que tuviste conocimiento en fechas límite concretas.
Preguntas frecuentes
¿El Reglamento de Ciberresiliencia exige un security.txt?
No. El reglamento espera que los fabricantes tengan una política de divulgación coordinada de vulnerabilidades y una vía publicada para informar de ellas. Un archivo security.txt es la forma habitual de publicar ese contacto y los profesionales lo recomiendan, pero el reglamento no menciona el formato. Consulta la guía para pequeños proveedores.
¿Dónde exactamente pongo el archivo?
En https://tu-dominio/.well-known/security.txt, servido por HTTPS con el tipo de contenido text/plain; charset=utf-8. La RFC 9116 también permite una copia en /security.txt para instalaciones antiguas. Publícalo en cada dominio o subdominio que quieras cubrir.
¿Con cuánta anticipación debe estar Expires?
La RFC 9116 indica que debe ser dentro de menos de un año, para que los investigadores confíen en que los datos de contacto se mantienen al día. El generador propone una fecha de poco menos de un año a partir de hoy. Cuando la fecha pasa, se indica a los lectores que ignoren el archivo, así que renuévalo a tiempo.
¿Tengo que firmar el archivo con PGP?
No, firmar es opcional pero recomendable. Un archivo firmado es un mensaje firmado en texto claro con OpenPGP, que se crea con gpg --clearsign security.txt. El verificador reconoce el formato firmado y revisa su estructura, pero no puede verificar la firma en sí; para eso usa gpg --verify.
¿Por qué el verificador no puede consultar mi sitio?
Para proteger tu privacidad: funciona por completo en tu navegador y no hace solicitudes a otros sitios. Abre tu archivo en una pestaña del navegador, copia el texto y pégalo aquí. Así además compruebas lo que realmente reciben los visitantes.
¿Para qué sirve el campo Canonical?
Enumera las direcciones donde debe publicarse el archivo, de modo que quien lo lea pueda confirmar que un archivo encontrado en una dirección realmente le corresponde. Si escribes la dirección desde la que publicas el archivo, el verificador comprueba que una de tus líneas Canonical coincida con ella.