Generador de security.txt: crea y valida un archivo RFC 9116

Crea un security.txt válido (RFC 9116) con campos de contacto, caducidad, cifrado y política, comprueba uno existente y descárgalo para /.well-known/.

Direcciones de correo, formularios de informe https:// o números de teléfono. A los correos sin esquema se les añade mailto:. Pon primero el preferido.

Fecha y hora RFC 3339, a menos de un año vista. Ponte un recordatorio en el calendario para renovarlo antes de que caduque.

URL de tu clave pública PGP (https://, dns: u openpgp4fpr:), no la clave en sí.

Etiquetas de idioma separadas por comas, por ejemplo en, fr, pt-BR.

La URL o URL https:// donde está este archivo. En la práctica es obligatoria si lo firmas.

Tu política de divulgación de vulnerabilidades: alcance, puerto seguro y cómo respondes.

Una página de agradecimiento a los investigadores que han informado de problemas (salón de la fama).

Ofertas de empleo en seguridad.

Para proveedores que publican avisos legibles por máquina: URL de provider-metadata.json.

Válido: están todos los campos obligatorios y cada valor cumple RFC 9116.

security.txt
…
Dónde colocarlo
  • Sírvelo en https://yourdomain.com/.well-known/security.txt por HTTPS, como text/plain; charset=utf-8. Opcionalmente, redirige /security.txt a él.
  • Next.js, Astro, Vite y la mayoría de hostings estáticos: guárdalo como public/.well-known/security.txt. WordPress, Apache o nginx: crea una carpeta .well-known en la raíz web.
  • Cada subdominio que sirva su propio sitio debería tener su propio archivo (o remitir al principal en un comentario).
  • Opcional: fírmalo con gpg --clearsign security.txt y publica el resultado firmado; incluye Canonical para que la firma cubra la ubicación.

Funciona por completo en tu navegador. Nada de lo que introduces se nos envía ni se guarda. Ver todas las herramientas gratis.

¿Encontraste un problema o algo que podría mejorar? Leemos todos los mensajes y lo arreglamos rápido.

Este generador de security.txt gratis crea el pequeño archivo de texto, estandarizado como RFC 9116, que indica a los investigadores de seguridad cómo informar de una vulnerabilidad en tu sitio. Rellena un contacto, una fecha de caducidad y, si quieres, tu clave de cifrado, tu política de divulgación, tu página de agradecimientos, los idiomas preferidos y la URL canónica; el archivo se valida según la RFC mientras escribes y se descarga como security.txt, listo para subirlo a /.well-known/security.txt.

Sin él, quien encuentra un fallo en tu sitio tiene que adivinar adónde enviarlo, y los informes acaban en el buzón de soporte, en redes sociales o en ninguna parte. El archivo se hace en cinco minutos y lo comprueban muchos escáneres de seguridad e investigadores de bug bounty. La segunda pestaña valida un archivo que ya publicas. La herramienta no firma el archivo (usa gpg para eso) ni descarga tu archivo publicado, porque la página no hace peticiones de red.

Cómo usarla

  1. Introduce al menos un Contact: un email de seguridad, la URL de un formulario de informe o un número de teléfono. Pon primero el preferido.
  2. Define Expires con uno de los botones (seis meses es un buen valor por defecto) o escribe una fecha y hora RFC 3339.
  3. Añade los campos opcionales que tengas: la URL de tu clave PGP, tu política de divulgación, una página de agradecimientos, los idiomas que lees y la URL canónica del archivo.
  4. Corrige lo que aparezca marcado en rojo; lo que está en ámbar son recomendaciones.
  5. Descarga security.txt y publícalo en https://yourdomain.com/.well-known/security.txt, servido como text/plain. Ponte un recordatorio para actualizar Expires.

Preguntas frecuentes

¿Qué es security.txt?

Un archivo de texto plano en /.well-known/security.txt que indica cómo informar de vulnerabilidades de seguridad en un sitio web o un producto. El IETF lo publicó como RFC 9116 en abril de 2022. Solo hay dos campos obligatorios, Contact y Expires; el resto (Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy, Hiring) son opcionales.

¿Dónde pongo el archivo security.txt?

En https://yourdomain.com/.well-known/security.txt, servido por HTTPS con el tipo de contenido text/plain; charset=utf-8. Algunas herramientas siguen leyendo la ubicación antigua /security.txt en la raíz; puedes servir una copia ahí o redirigirla. En Next.js, Astro, Vite y la mayoría de los alojamientos estáticos, coloca el archivo en public/.well-known/. Cada nombre de host que sea un sitio independiente debería tener su propio archivo.

¿Por qué es obligatorio el campo Expires?

Para que no se confíe para siempre en datos de contacto obsoletos. RFC 9116 hace obligatorio Expires y recomienda una fecha a menos de un año vista; cuando pasa, los investigadores y los escáneres deberían considerar el archivo desactualizado. Seis meses con un recordatorio en el calendario para renovarlo es un ritmo práctico, y el generador avisa cuando la fecha ya ha pasado o está a más de un año.

¿Debo firmar security.txt?

La firma es opcional, pero recomendable. Ejecuta gpg --clearsign security.txt con una clave cuya parte pública publiques (el campo Encryption puede apuntar a ella) y sube la salida firmada en su lugar. Si firmas, incluye un campo Canonical, para que una copia firmada tomada de una URL no pueda hacerse pasar por válida en otra.

¿Puedo usar el enlace de una plataforma de bug bounty como contacto?

Sí. Contact acepta cualquier URI https://, así que la página de un programa de HackerOne, Bugcrowd, Intigriti o YesWeHack, o tu propio formulario de informe, es válida. Muchas organizaciones indican tanto un enlace a una plataforma como una dirección de email, por orden de preferencia.

Los campos de RFC 9116 de un vistazo

• Contact (obligatorio, repetible): URI mailto:, https: o tel:. El orden indica la preferencia.

• Expires (obligatorio, exactamente una vez): fecha y hora RFC 3339 como 2027-04-30T23:59:59Z; se recomienda a menos de un año vista.

• Encryption (repetible): dónde obtener tu clave pública, como https://, dns: (registro OPENPGPKEY) u openpgp4fpr: (huella). Nunca pegues la clave en sí.

• Acknowledgments (repetible): una página de agradecimiento a quienes informan.

• Preferred-Languages (una vez): etiquetas de idioma separadas por comas, p. ej. en, fr.

• Canonical (repetible): la URL o URL donde debe estar este archivo.

• Policy (repetible): tu política de divulgación de vulnerabilidades.

• Hiring (repetible): ofertas de empleo relacionadas con la seguridad.

• CSAF (repetible, registrado por OASIS): el provider-metadata.json de un feed de avisos CSAF.

Las URI web deben usar https://. Las líneas que empiezan por # son comentarios.

Qué escribir en tu política de divulgación

El enlace de Policy es donde los investigadores averiguan si es seguro informar. Indica el alcance (qué dominios y aplicaciones), lo que queda fuera de él (denegación de servicio, ingeniería social, resultados de escáneres automáticos), con qué rapidez acusarás recibo y corregirás los informes, si ofreces recompensas y una cláusula de puerto seguro que diga que no emprenderás acciones legales contra la investigación de buena fe que siga la política. Una página breve y clara consigue informes más útiles que una larga y legalista.

security.txt y robots.txt

Conviven, pero hacen trabajos distintos: robots.txt pide a los rastreadores qué no deben descargar, y security.txt indica a las personas cómo llegar a tu contacto de seguridad. No pongas security.txt ni /.well-known/ bajo Disallow; los investigadores y los escáneres necesitan leerlo, y bloquearlo en robots.txt tampoco lo oculta.

Herramientas gratis relacionadas

  • Generador de robots.txt — Crea un robots.txt con ajustes predefinidos para permitir todo, entornos de pruebas y WordPress, una sección de rastreadores de IA (bloquear el entrenamiento, mantener la búsqueda con IA) y avisos de los errores que desindexan sitios.
  • Generador de contraseñas — Genera una contraseña aleatoria segura, una frase de contraseña fácil de recordar o un PIN. Funciona por completo en tu navegador: no se envía ni se guarda nada.
  • Generador de metaetiquetas — Rellena el título, la descripción y los datos de la tarjeta social de una página y obtén un bloque <head> completo y bien escapado, con contadores de longitud en vivo.
  • Decodificador de JWT — Decodifica la cabecera y el payload de un JWT, lee la caducidad en lenguaje claro, verifica firmas HS, RS, PS y ES o firma un token nuevo. Nada sale de tu navegador.