Comprobación de security.txt
Introduce un sitio para ver si indica a los investigadores de seguridad dónde comunicar un problema, y si ese archivo está en el lugar correcto, bien formado y todavía vigente. Si no hay ninguno, puedes escribirlo más abajo.
Escribe un security.txt
Rellena lo que corresponda y copia el resultado. El archivo se arma dentro de esta página: nada de lo que escribas aquí se nos envía.
Una dirección de correo electrónico o la dirección https:// de un formulario. Usa un buzón compartido, no una persona: la gente se va.
Una página que diga qué se puede probar y qué puede esperar de ti quien informa.
Códigos de idioma separados por comas.
Añade una línea Canonical, que ata el archivo a su dirección.
Preajustado a un año desde hoy, el máximo que recomienda el estándar.
- Guarda el texto como un archivo llamado
security.txt, codificado en UTF-8. - Súbelo a una carpeta llamada
.well-knownen la raíz del sitio, de modo que responda enhttps://tu-dominio/.well-known/security.txt. - Ejecuta la comprobación de arriba: el archivo debe llegar por HTTPS como
text/plain. - Anota la fecha de caducidad en un calendario. Un archivo caducado es peor que ninguno, porque parece abandonado.
Una puerta de entrada para las malas noticias
Tarde o temprano, alguien ajeno a tu organización detecta algo que falla en tu sitio: una página que muestra los pedidos de otros clientes, un panel de administración olvidado, un restablecimiento de contraseña que se puede repetir. La mayoría de esas personas quiere avisarte. Lo difícil es encontrar a quién avisar. El formulario de contacto va a ventas, el chat de soporte pide un número de pedido y nadie responde a info@.
Un archivo security.txt resuelve ese único problema. Son unas pocas líneas de texto sin formato en una dirección fija, /.well-known/security.txt, que dicen adónde van los informes y hasta cuándo es válida esa información. El formato se publicó como RFC 9116 en 2022. Los escáneres, las plataformas de recompensas por errores y las agencias nacionales de seguridad leen el archivo automáticamente cuando tienen algo que comunicar.
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyQué lee esta comprobación
Nuestro servidor solicita https://your-host/.well-known/security.txt y, si la primera no devuelve nada, la dirección antigua /security.txt en la raíz. Se siguen las redirecciones. Una respuesta con estado 200 que resulta ser una página HTML cuenta como ausencia de archivo, porque muchos sitios responden con su página de inicio a cualquier dirección desconocida.
Cuando hay un archivo, lo juzgamos por tres cosas.
| Parte | Qué debe cumplirse |
|---|---|
| Cómo se sirve | En la dirección /.well-known/, por HTTPS, con Content-Type: text/plain. Se señala una redirección a otro dominio. |
Contact | Al menos uno, cada uno como URI: mailto:, https:// o tel:. Una dirección de correo electrónico sin mailto: es un error. |
Expires | Exactamente uno, escrito como marca de tiempo completa, por ejemplo 2027-01-31T00:00:00.000Z, y en el futuro. Caducado es un error; menos de 30 días restantes o más de un año por delante es una advertencia. |
| Campos opcionales | Encryption, Acknowledgments, Policy, Hiring y CSAF deben ser direcciones https://. Preferred-Languages aparece una sola vez y contiene códigos de idioma. Canonical debe incluir la dirección desde la que se leyó el archivo. |
Los nombres de campo ajenos al estándar se enumeran sin penalización, porque las extensiones están permitidas. La comprobación también indica si el texto va envuelto en una firma en texto claro de OpenPGP. No verifica esa firma.
Los errores que más vemos
- Una fecha caducada
- Alguien escribió el archivo una vez y se olvidó de él. La RFC 9116 dice que un archivo caducado no debe usarse, así que quien quiere avisar vuelve a tener que adivinar. Renovarlo lleva dos minutos: confirma los contactos, cambia la fecha y publica.
- Ningún
Expires - Los archivos escritos antes de 2022 seguían un borrador en el que el campo era opcional. Ahora es obligatorio.
Contact: security@example.com- El valor tiene que ser un URI. Escribe
mailto:security@example.com. - El archivo solo en la raíz
/security.txtes una alternativa. Pon el archivo en/.well-known/y redirige la dirección antigua hacia él.- Un
Canonicalcopiado de otro sitio - Si el campo está y no incluye la dirección desde la que se sirve el archivo, el archivo se contradice a sí mismo.
Publicar uno que puedas mantener vivo
Empieza por decidir quién lee el buzón. Una dirección compartida como security@ que llegue a dos personas es mejor que una persona con nombre. Después usa el generador de esta página. Añade mailto: donde hace falta, da formato a la fecha y la deja preajustada a un año vista.
Sube el resultado a una carpeta llamada .well-known en la raíz web. La mayoría de los servidores envían los archivos .txt como text/plain sin que se lo digas. Si el tuyo oculta las carpetas que empiezan por un punto, añade una excepción. En nginx:
location = /.well-known/security.txt {
default_type text/plain;
charset utf-8;
}Firmar es opcional. Con GnuPG, gpg --clearsign security.txt produce una versión firmada para publicar en su lugar. Incluye una línea Canonical antes de firmar para que la firma cubra también la dirección.
Esta página lee un host, una vez. No puede saber si alguien responde en la dirección de contacto, si existe la política enlazada o si la firma es auténtica. Que falte el archivo no es un fallo de seguridad y no baja ninguna nota aquí.
Preguntas frecuentes
¿Es una vulnerabilidad que falte el security.txt?
No. El archivo es una cortesía que facilita informar, y por sí solo no protege nada. Algunos escáneres automáticos incluyen su ausencia como un hallazgo de gravedad baja. Tómalo como una sugerencia.
¿Dónde va exactamente el security.txt?
En https://your-domain/.well-known/security.txt, servido por HTTPS como texto sin formato. Cada host es independiente, así que un archivo en example.com no cubre app.example.com.
¿Publicar una dirección de contacto atraerá spam o informes de errores falsos?
Espera algunos informes automáticos de poco valor, que a menudo piden una recompensa. Una página de política breve que diga qué consideras dentro del alcance, y si pagas recompensas, filtra la mayoría. Apuntar Contact a un formulario web en vez de a un buzón también ayuda.
¿Cuánto tiempo debe abarcar la fecha de Expires?
Menos de un año por delante, como recomienda la RFC. La fecha es una promesa de que los contactos eran correctos cuando se revisó el archivo por última vez, y por eso debe ser corta. Pon un recordatorio un mes antes de que pase.
¿Necesito firmar el archivo con PGP?
No. Una firma ayuda a quien lo lee a confirmar que el archivo no fue alterado en un servidor comprometido, y solo funciona si tu clave pública se puede obtener en otro sitio. Hay muchos archivos válidos sin firmar.
¿Cuál es la diferencia entre security.txt y robots.txt?
Ambos son archivos de texto sin formato en una dirección conocida, leídos por software. robots.txt dice a los rastreadores qué páginas dejar en paz. security.txt dice a las personas que encontraron un problema de seguridad cómo llegar hasta ti. Ninguno de los dos obliga a nada.