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-text.

Consejos

  • La ubicación oficial de security.txt es /.well-known/security-text. 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.

Preguntas frecuentes

La RFC 9116 especifica https://example.com/.well-known/security-text 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.

El archivo no se invalida automáticamente, pero los investigadores de seguridad y las herramientas automatizadas lo tratarán como información obsoleta y sin mantenimiento, lo que reduce su fiabilidad. Se recomienda extender la fecha al menos una vez al año.

No, son cosas distintas. security.txt es un archivo de contacto que indica a quién dirigirse y cómo; no define si existe una recompensa económica ni su importe. Sí puedes enlazar a una página de recompensas desde el campo Policy o Hiring.

Puedes escribirla, pero la RFC 9116 define Contact como una URI, por lo que debe llevar un esquema, como mailto:[email protected]. Sin esquema, los analizadores automáticos podrían no reconocerla correctamente.

No es obligatorio, pero la RFC 9116 recomienda una firma OpenPGP. Al firmarlo, los investigadores pueden verificar que el contenido del archivo no ha sido alterado por terceros.
ツールくん

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-text, 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.