Generador y validador de security.txt

Qué es security.txt

Un archivo security.txt es un archivo de texto breve que indica a quien haya encontrado una vulnerabilidad en tu sitio dónde tiene que avisar. Antes de que existiera, el investigador que detectaba algo raro tenía que adivinar: probar con security@ y confiar en que alguien lo leyera, rebuscar en una página de contacto, o rendirse y callarse. El archivo cambia esa adivinanza por una ubicación fija y un puñado de campos con nombre, y en abril de 2022 se convirtió en estándar: el RFC 9116.

El formato es deliberadamente sencillo. Cada línea es un nombre de campo, dos puntos, un espacio y un valor, y las líneas que empiezan por # son comentarios. Solo dos campos son obligatorios: Contact, que dice dónde enviar los avisos, y Expires, que dice a partir de cuándo deja de ser fiable la información. Todo lo demás —el enlace a tu política, una clave de cifrado, una página de agradecimientos, los idiomas que lees— es opcional.

También es lo bastante pequeño como para equivocarse sin que nadie se entere, y para eso está el comprobador de esta página. De los archivos que publican los 500 dominios con más tráfico de la web, menos de la mitad cumplen hoy el estándar con el que están escritos.

Cómo se usa

1. Pon tu contacto y la caducidad. Contact tiene que ser un URI, así que una dirección de correo necesita el prefijo mailto: y un teléfono necesita tel:. El campo de caducidad viene relleno a un año vista, que es el máximo que recomienda el estándar.
2. Añade los campos opcionales que necesites. Un enlace a la política, una clave OpenPGP, una página de agradecimientos, los idiomas que lees. Contact y casi todos los demás pueden repetirse; Expires y Preferred-Languages, no.
3. Publícalo, o revisa el que ya tienes. El archivo va en /.well-known/security.txt por HTTPS. Cambia a la pestaña de comprobación para pegar un archivo existente y ver cada problema con su número de línea.

En qué fallan los archivos publicados

Las cifras salen de pedir las dos ubicaciones posibles a los 500 dominios con más tráfico de la web según el ranking Tranco, y pasar todo lo que respondió por el mismo comprobador que ofrece esta página. 115 de esos dominios publican algo; 45, el 39,1 %, no tienen ningún error.

El fallo más frecuente con diferencia es que falte el campo Expires: 48 archivos, el 41,7 % de todo lo publicado. No es una regla oscura —Expires es uno de los dos únicos campos obligatorios— y tiene una explicación limpia. Expires no existía en los primeros borradores a partir de los que todo el mundo implementó; se añadió camino de convertirse en RFC. Así que el problema más habitual es el campo que el estándar añadió el último, en archivos que eran correctos cuando se escribieron.

La caducidad falla además de otra manera: 11 de estos archivos declaran que ya han caducado, lo que según la propia definición del estándar significa que su contenido ya no debería usarse. El de una red social muy conocida daba una fecha de enero de 2024. Otros trece la empujan tan lejos que nunca llegará a vencer de forma útil: el de un gran buscador dice 2030, casi cuatro años vista, frente a una recomendación de no pasar de uno.

Catorce archivos dan un Contact que no es un URI. Esta es la trampa que el formato tiende a quien escribe lo que parece obvio: una dirección suelta como psirt@example.com se lee perfectamente y es inválida, porque el campo está especificado como URI y necesita mailto: delante. Una conocida empresa de software publica un contacto https correcto y justo en la línea siguiente una dirección suelta. Si necesitas construir uno, nuestro generador de enlaces mailto lo escribe entero.

Dieciséis archivos tienen alguna línea que no es un campo, casi siempre un título con espacios, y unos cuantos son directamente prosa: un párrafo explicando cómo avisar de un fallo, publicado en la ruta donde se esperaba un archivo legible por máquina. Seis no tienen ningún campo Contact, porque se han inventado su propio nombre para él.

Dónde va el archivo y qué queda fuera

El estándar es concreto con la ubicación: el archivo tiene que estar en /.well-known/security.txt. Una copia en la raíz del sitio solo se admite por compatibilidad histórica, y cuando existen las dos manda la de well-known. Veintiséis de los dominios medidos lo sirven en ambas, lo cual está bien; ocho lo sirven solo en la raíz, de modo que una herramienta que siga el estándar puede no mirar nunca ahí.

El alcance del archivo es más estrecho de lo que casi todo el mundo supone. Vale solo para el dominio o la IP exactos desde los que se descargó: ni para los subdominios ni para el dominio padre. Un archivo en example.com no dice nada sobre cualquiera.example.com, y cada host que necesite uno necesita el suyo.

Los campos desconocidos no son errores. El estándar ordena a quien lee el archivo que ignore cualquier campo que no reconozca, así que el comprobador señala un nombre no registrado como nota y no como problema. Es una decisión deliberada del estándar, y un validador que lo marcara como inválido estaría contradiciendo justo el documento con el que valida.

Dos de los campos que aparecen en esta página no están en ninguna parte del RFC 9116. El registro lo mantiene IANA, y ha crecido desde la publicación: CSAF, que apunta a un canal de avisos legible por máquina y es el único campo del formato cuyo control de cambios no está en el IETF, y Bug-Bounty, el único cuyo valor no es ni un URI, ni una fecha, ni una etiqueta de idioma, sino simplemente True o False.

Algo que esta página no hace es verificar firmas. Un archivo puede ir envuelto en una firma OpenPGP, y dieciocho de los medidos lo están; los campos de dentro se revisan con normalidad, pero comprobar una firma implicaría manejar claves, que es un trabajo distinto de leer un formato de texto.

¿Por qué es gratis?

Todo esto es un formato de texto. Generar un archivo es concatenar cadenas y comprobarlo es un analizador, y las dos cosas se ejecutan en tu navegador, así que no hay servidor que pagar ni cuenta que crear.

Nada de lo que escribes se sube, se guarda ni se registra. Aquí importa más que en la mayoría de páginas: un archivo de contacto de seguridad es público por definición, pero el borrador que aún estás editando no lo es, ni tampoco el archivo que has pegado para averiguar qué le pasa.