Prepara denuncias de abuso para registradores, proveedores de hosting y CDN, como correo y como JSON.
Nueva
Generador de security.txt
Se ejecuta localmente
La herramienta en sí está en inglés; en esta página se explica en tu idioma.
Utiliza Generador de security.txt
Para qué sirve
Crea un archivo security.txt para que los investigadores y quienes denuncian phishing que imita tu marca sepan cómo contactar contigo. Guarda el resultado como /.well-known/security.txt.
Funciona íntegramente en tu navegador: no se sube nada de lo que introduzcas.
Cómo utilizar Generador de security.txt
- Introduce un contacto. Escribe en «Contacto» cómo ponerse en contacto con tu equipo de seguridad, una por línea: mailto:security@example.com, una dirección https:// de un formulario de informe o un número de teléfono. Si se introduce solo una dirección de correo electrónico, se le añadirá «mailto:».
- Fija la fecha de caducidad. Elige una fecha en Expires. La predeterminada es dentro de un año; RFC 9116 recomienda menos de un año, así que elige una fecha anterior.
- Añade campos opcionales. Rellena Preferred-Languages (en por defecto), Canonical, Policy, Encryption, Acknowledgments y Hiring si los tienes. Los campos vacíos se omiten del archivo.
- Genera y copia. Pulsa Generate (Generar) y lee el resultado en el recuadro de salida. Revisa una vez más cada dirección, porque la herramienta las copia tal como se escriben, y después pulsa Copy (Copiar).
- Publica y renueva. Guarda el texto como /.well-known/security.txt en tu sitio por HTTPS, fírmalo con gpg --clearsign si quieres y anota una fecha para renovarlo antes de que caduque.
Ejemplo
Archivo mínimo
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enGenera «Contact: mailto:security@example.com», una línea «Expires» con una vigencia de un año a partir de las 23:59:59Z y «Preferred-Languages: en»: los dos campos obligatorios más una indicación del idioma, con un recordatorio de que la RFC 9116 recomienda que la fecha de caducidad sea inferior a un año.
Qué comprueba
| Señal | Qué significa |
|---|---|
| Contact: | Una línea por contacto, en el orden en que los hayas escrito. Cada uno debe ser un URI del tipo «mailto:», «https://» o «tel:», tal y como establece el RFC 9116; los valores del tipo «http://» y los que tengan un formato incorrecto generarán un error en lugar de mostrar un archivo. |
| Expires: | La fecha elegida a las 23:59:59 UTC, escrita con milisegundos, por ejemplo 2027-03-31T23:59:59.000Z. Si vacías el campo de la fecha, Generate deja de producir un archivo nuevo. |
| Preferred-Languages: | en por defecto. Usa códigos de idioma separados por comas, como en, de, o vacía el campo para omitir la línea. |
| Canonical: | La dirección https:// completa donde está este archivo, para que se pueda reconocer una copia servida desde otro lugar. |
| Encryption: | Un enlace a tu clave pública OpenPGP, para que quienes denuncian puedan cifrar los detalles sensibles. |
| Policy, Acknowledgments, Hiring | Enlaces a tu política de divulgación, a una página de agradecimiento a quienes informan y a ofertas de empleo en seguridad. Todos son opcionales, y la herramienta no comprueba que los enlaces funcionen. |
| Una dirección de rol en Contact | Usa una dirección o un formulario que vigile un equipo, como security@ de tu dominio, no el buzón de una persona, para que las denuncias sigan llegando cuando la gente cambie de puesto. |
| Error: Contact is required | Se muestra cuando el campo «Contacto» está vacío. Cualquier error sustituye el resultado por una nota que indica que no se ha generado nada hasta que se corrijan los campos. |
Más ejemplos
Formulario web con idiomas y política
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyCinco líneas en este orden: Contact: https://example.org/report-security, Expires: 2027-03-31T23:59:59.000Z, Preferred-Languages: en, de, Canonical: https://example.org/.well-known/security.txt, Policy: https://example.org/security-policy.
Contacto por correo con clave, sin idioma
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtTres líneas: Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z y Encryption: https://example.net/pgp-key.txt.
Contact vacío
All fields filled except ContactError: Es necesario rellenar el campo «Contacto», y aparece un mensaje indicando que no se ha generado nada. Los demás campos conservan sus valores, así que rellena el campo «Contacto» y vuelve a pulsar «Generar».
Preguntas frecuentes
¿Qué campos son obligatorios?
La RFC 9116 exige que haya al menos un campo «Contact» y exactamente un campo «Expires»; el resto son opcionales. Cada línea «Contact» debe ser un URI «mailto:», «https://» o «tel:» (a una dirección de correo electrónico sin formato se le añade «mailto:»); «Expires» debe ser una fecha futura, y «Generate» muestra un error en lugar de un archivo cuando falta alguno de estos campos o alguno de ellos no es válido.
¿Qué fecha debo poner en Expires?
La fecha predeterminada es un año a partir de hoy, mientras que el RFC 9116 recomienda que sea inferior a un año, así que elige una fecha anterior para cumplir con lo establecido; la página te avisa cuando la fecha se sitúe más de un año en el futuro. Renueva el archivo antes de esa fecha, ya que el RFC establece que un archivo security.txt caducado debe considerarse obsoleto.
¿Sube o firma algo?
No. El archivo se genera en tu navegador y no se envía nada a ningún sitio. No está firmado; RFC 9116 recomienda una firma OpenPGP en texto claro, que puedes añadir con gpg --clearsign antes de publicarlo.
¿Puedo indicar más de un contacto?
Sí. El RFC 9116 permite incluir varias líneas de contacto, que se leen por orden de preferencia. Escribe un contacto por línea en el campo «Contacto»; los contactos duplicados se registran una sola vez.
¿Dónde va exactamente el archivo?
En https://tu-dominio/.well-known/security.txt, servido por HTTPS como texto sin formato. Una copia o una redirección en /security.txt es opcional.
¿Un solo archivo cubre mis subdominios?
No. RFC 9116 dice que un security.txt solo se aplica al host desde el que se obtuvo, no a sus subdominios ni a su dominio superior. Publica una copia en cada host donde la gente pueda buscarlo, como www y shop.
¿Cómo ayuda security.txt contra el phishing que copia mi marca?
Quienes encuentran un sitio que imita al tuyo o un correo falso en tu nombre a menudo quieren avisarte. Una línea Contact que funcione hace llegar esa denuncia a tu equipo de seguridad en lugar de a una cola general de soporte, para que puedas actuar antes contra el dominio imitador.