Validador de security.txt
Pega el contenido de tu security.txt (RFC 9116) para detectar errores de sintaxis. Verifica campos obligatorios como Contact y Expires y el formato de sus valores, para confirmar que está publicado correctamente en /.well-known/security.txt.
Validar el formato de un security.txt
Un security.txt es el archivo de texto con el que un sitio indica a quien haya hallado una vulnerabilidad adónde dirigirse, y su formato lo fija la RFC 9116. Pegue su contenido y esta herramienta comprueba la sintaxis, confirmando que campos obligatorios como `Contact` y `Expires` están presentes y que sus valores adoptan la forma debida.
**Lo que suele pasarse por alto aquí es el tratamiento de `Expires`.** No solo es un campo obligatorio, sino que **un archivo cuyo momento declarado ya pasó se considera no válido.** Publíquelo y desentiéndase, y al cabo de unos años seguirá ahí pero inerte, de modo que conviene gestionarlo junto con un plan de renovación. **Su ubicación también está fijada: le corresponde `/.well-known/security.txt`.** Cuando el archivo va firmado, el campo `Canonical` declara la URL autorizada para que el lector pueda cerciorarse de que nadie lo ha manipulado.
Cómo se usa
- Pegue el contenido de su security.txt Introduzca el archivo entero tal como está.
- Pruebe antes con los ejemplos Se ofrecen tanto un ejemplo válido como otro con errores.
- Lea los puntos señalados **Se informa de los campos obligatorios ausentes y de los valores mal formados.**
- Compruebe el momento indicado en `Expires` **Confirme que no queda en el pasado y decida de antemano cuándo lo renovará.**
Consejos para aprovecharla mejor
- La ubicación oficial de security.txt es
/.well-known/security.txt. Por compatibilidad, conviene publicar también una copia en/security.txt(la raíz del sitio). - Escribe Contact como una URI con esquema, por ejemplo mailto:, https: o tel:. Una dirección de correo sin esquema no cumple con la RFC 9116 y puede no ser reconocida por analizadores automáticos.
- Fija Expires a no más de un año vista y renuévalo cada vez que lo actualices. Un archivo caducado corre el riesgo de tratarse como un contacto abandonado.
- Toda la validación de esta herramienta se ejecuta enteramente en tu navegador: nada de lo que pegues se envía a ningún servidor, así que puedes comprobar un archivo con total tranquilidad antes de publicarlo.
Cuándo resulta útil
Hacer explícito su contacto de seguridad
Quien halle algo no tendrá que buscar una dirección, con lo que el aviso llegará mucho más fácilmente.
Revisar lo que ha publicado
**Un archivo mal formado no da señal externa alguna, así que solo la validación lo revela.**
Prevenir la caducidad
Puede comprobar cada cierto tiempo que `Expires` no ha vencido.
Mantener un estándar en la organización
Cuando se gestionan varios sitios, puede confirmar que todos siguen el mismo formato.
Términos de security.txt
- Contact
- Campo **obligatorio** que da un medio de contacto: una dirección de correo, un teléfono o la URL de un formulario de aviso.
- Expires
- Campo **obligatorio** tras cuyo momento declarado el archivo se considera ya no válido.
- Encryption
- Señala una clave pública con la que puede cifrarse un aviso.
- Policy
- La URL de una página que expone la política sobre divulgación de vulnerabilidades.
- Canonical
- La URL autorizada en la que este archivo ha de residir. **Es aquello contra lo que se coteja una firma.**
- Preferred-Languages
- Declara los idiomas en que pueden recibirse los avisos, separados por comas como en `en, ja`.
Preguntas frecuentes
https://example.com/.well-known/security.txt como ubicación oficial. Como muchas implementaciones también comprueban la ruta heredada https://example.com/security.txt, se recomienda publicarlo en ambos sitios por compatibilidad.mailto:[email protected]. Sin esquema, los analizadores automáticos podrían no reconocerla correctamente.
A propósito — El origen de security.txt — el "primer punto de contacto" que los programas de recompensas por errores no bastaban para ofrecer
security.txt fue propuesto en 2017 por los investigadores de seguridad Ed Overflow y Kagan Baytas. En aquel entonces, quienes descubrían una vulnerabilidad a menudo no tenían una vía clara para reportarla, y terminaban usando un formulario de contacto genérico o un mensaje directo en redes sociales. Los informes tardaban mucho en llegar a la persona adecuada, o directamente se ignoraban.
La propuesta se llevó al IETF (Internet Engineering Task Force) y, tras años de debate y revisión, se convirtió en el estándar oficial RFC 9116 en 2022. El mecanismo es sencillo: el operador del sitio publica un único archivo de texto en /.well-known/security.txt, y los investigadores pueden determinar de forma mecánica a quién contactar, en qué idioma y bajo qué política.
Grandes empresas tecnológicas como GitHub, Google, Facebook y LinkedIn han adoptado security.txt, y es habitual ver un enlace a un programa de divulgación de vulnerabilidades o de recompensas por errores a través del campo Policy. Funciona como una auténtica "puerta de entrada" que llega a investigadores que quizá nunca habrían encontrado por sí solos una plataforma de recompensas.
Como extensión natural de la RFC 9116, cada vez más organizaciones enlazan documentos CSAF (Common Security Advisory Framework) mediante el campo CSAF, estandarizando así el intercambio de avisos de vulnerabilidad. security.txt ha dejado de ser un simple archivo de contacto para convertirse en la puerta de entrada de todo el proceso de respuesta de seguridad de una organización.