Herramientas GitHub Pages

Gratis Generador & validador security.txt

Genera y valida archivos security.txt según RFC 9116 con guía de alojamiento.

Cargando herramienta...

Qué es Generador & validador security.txt?

security.txt es un archivo de texto simple publicado en /.well-known/security.txt que indica a los investigadores de seguridad cómo contactarlo sobre vulnerabilidades. Está definido por RFC 9116 y es compatible con Google, GitHub y las principales plataformas de divulgación de vulnerabilidades. El archivo contiene un campo Contact (URL o correo), una fecha Expires y campos opcionales para Canonical, Encryption, Policy, Acknowledgments y Hiring.

Respuesta rápida

security.txt es un archivo en /.well-known/security.txt que indica a los investigadores de seguridad cómo reportar vulnerabilidades. Como mínimo, incluya un campo Contact (URL o correo) y una fecha Expires. Renueve el archivo antes de que venza para mantener activo su canal de divulgación de vulnerabilidades.

Last updated: 2026-05-28

Limitaciones

  • security.txt es un estándar propuesto (RFC 9116), no una recomendación W3C. La adopción de escáneres automatizados varía según la región y la industria.
  • El archivo debe servirse a través de HTTPS sin redirecciones. Algunas plataformas de alojamiento estático pueden redirigir rutas /.well-known/ o servirlas con tipos de contenido inesperados.
  • security.txt por sí solo no crea un programa de divulgación de vulnerabilidades o bug bounty. Solo indica a los investigadores dónde reportar — aún necesita un proceso interno para manejar los informes entrantes.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

Cómo usar esta herramienta

  1. En modo Generar: complete su URL o correo de contacto, establezca una fecha de vencimiento y agregue los campos opcionales que necesite.
  2. En modo Validar: pegue un archivo security.txt existente para verificarlo según la especificación RFC 9116.
  3. Implemente el archivo en /.well-known/security.txt en su dominio y sírvalo a través de HTTPS.

Para qué puedes usarla

  • Crear un contacto de divulgación de vulnerabilidades para el sitio de un proyecto de código abierto.
  • Validar un security.txt existente antes de implementarlo en un dominio de producción.
  • Asegurarse de que la fecha Expires no esté en el pasado y que el campo Contact use una URL o formato de correo válido.

Casos de uso

Ejemplos prácticos

Ejemplo

Página de contacto de seguridad para un sitio SaaS

Una empresa SaaS crea un security.txt con un correo security@ dedicado y un enlace a su página de política de divulgación de vulnerabilidades. El archivo se coloca en el directorio /.well-known/ y se sirve a través de HTTPS.

Ejemplo

Sitio estático de código abierto

Un sitio de herramientas de código abierto alojado en GitHub Pages añade un security.txt con un enlace a su página de GitHub Security Advisories. El archivo incluye Preferred-Languages y una clave Encryption para informes cifrados con PGP.

Errores comunes

  • Colocar security.txt en la raíz del sitio en lugar de /.well-known/security.txt — la ruta /.well-known/ es requerida por RFC 9116.
  • Dejar que la fecha Expires pase sin renovación — los escáneres automatizados ignoran los archivos security.txt vencidos.
  • Servir el archivo a través de HTTP en lugar de HTTPS — el archivo debe ser accesible a través de HTTPS sin redirecciones.

Verificación

  1. Visite https://sudominio.com/.well-known/security.txt en un navegador y confirme que se carga directamente a través de HTTPS sin redirecciones.
  2. Use curl -I https://sudominio.com/.well-known/security.txt para verificar que el Content-Type sea text/plain y el estado de respuesta sea 200.

FAQ

Preguntas sobre Generador & validador security.txt

¿Dónde exactamente debo colocar el archivo security.txt?

Colóquelo en /.well-known/security.txt — la URL completa debe ser https://sudominio.com/.well-known/security.txt. Para GitHub Pages, cree un directorio .well-known en la raíz del sitio publicado y coloque security.txt dentro. El archivo debe servirse directamente, sin redirecciones.

¿Con qué frecuencia debo renovar la fecha Expires?

RFC 9116 recomienda establecer la fecha Expires a no más de 12 meses desde la fecha actual. Configure un recordatorio de calendario para renovarlo antes de que venza. Los escáneres automatizados y las plataformas de bug bounty ignoran los archivos security.txt vencidos.

¿Puedo tener más de un campo Contact?

Sí. RFC 9116 permite múltiples campos Contact. Esto es útil cuando tiene contactos de seguridad y abuso separados. Liste los contactos en orden de preferencia.

Herramientas relacionadas

Más herramientas github pages

Prueba también

Prueba también