security.txt es una mejor práctica de seguridad web formalmente estandarizada por el IETF (Internet Engineering Task Force) en el RFC 9116, cuyo objetivo es proporcionar a los sitios web una forma unificada y estándar de publicar información de contacto de seguridad. En pocas palabras, es un archivo de texto colocado en una ruta fija del sitio web que les dice a los investigadores de seguridad (hackers sombrero blanco): "Si encuentras una vulnerabilidad de seguridad en mi sitio web, aquí está la forma de contactarnos, esta es nuestra clave pública de cifrado, esta es nuestra política de divulgación, agradecemos tu informe."
Antes de que apareciera el estándar security.txt, la información de contacto de seguridad de los sitios web era caótica. Algunos sitios web no tenían ningún contacto de seguridad en absoluto, algunos lo ocultaban en una página en algún rincón, algunos solo dejaban un correo info@ que nadie revisaba, y algunos requerían esfuerzos en LinkedIn para encontrar al equipo de seguridad. Esto causaba un problema grave: cuando los investigadores de seguridad de buena fe encontraban vulnerabilidades, a menudo no encontraban el canal correcto para reportarlas. El resultado era que muchas vulnerabilidades quedaban en el olvido, sin ser corregidas, hasta que hackers maliciosos las encontraban y explotaban. security.txt nació precisamente para resolver este problema de la "última milla".
El concepto de security.txt fue propuesto originalmente por los investigadores de seguridad EdOverflow y Yakov Shafranovich en 2017, y obtuvo rápidamente un amplio apoyo de la industria. En abril de 2022, security.txt fue aprobado formalmente por el IETF como estándar RFC 9116, convirtiéndose en un estándar de seguridad web reconocido internacionalmente. Hoy en día, grandes empresas tecnológicas como Google, GitHub, Meta (Facebook), LinkedIn, Cloudflare, así como agencias gubernamentales como el gobierno del Reino Unido, CISA de EE. UU. (Agencia de Ciberseguridad y Seguridad de Infraestructuras), el gobierno de Francia, el gobierno de Italia, el gobierno de los Países Bajos y el Centro de Ciberseguridad de Australia ya han implementado security.txt en sus sitios web oficiales y recomiendan públicamente su adopción por otras organizaciones.
El diseño central del archivo security.txt es muy simple: es un archivo de texto plano compuesto por una serie de líneas de "nombre_campo: valor", similar al formato de encabezados HTTP. El estándar define dos campos obligatorios: Contact (contacto de seguridad, puede haber varios) y Expires (tiempo de vencimiento del archivo); así como varios campos opcionales: Encryption (URL de clave pública de cifrado PGP), Acknowledgments (URL de página de agradecimientos), Policy (URL de política de divulgación de vulnerabilidades), Hiring (URL de contratación de seguridad), Canonical (URL canónica del archivo), Preferred-Languages (idiomas admitidos para informes), CSAF (URL de metadatos del marco de avisos de seguridad). Este formato simple permite que tanto personas como máquinas lo analicen fácilmente.
¿Por qué es tan importante implementar security.txt? En primer lugar, reduce la barrera para reportar vulnerabilidades. Los investigadores de seguridad no necesitan pasar mucho tiempo buscando información de contacto, pueden encontrar el canal de reporte correcto con un clic. En segundo lugar, demuestra la actitud positiva de la organización hacia la seguridad: un sitio web con security.txt equivale a decir "valoramos la seguridad, agradecemos los informes responsables". En tercer lugar, reduce el riesgo de que las vulnerabilidades sean divulgadas públicamente o explotadas: los investigadores tienen un canal formal, por lo que no elegirán divulgar directamente la vulnerabilidad en Twitter o GitHub por no poder contactar. En cuarto lugar, en muchos requisitos regulatorios de la industria (como finanzas, salud, gobierno), establecer canales de divulgación de vulnerabilidades ya se ha convertido en un requisito de cumplimiento.
La implementación de security.txt requiere prestar atención a varios detalles clave. Primero, la ruta debe ser correcta: la ruta estándar es /.well-known/security.txt, también se puede colocar una copia en /security.txt en el directorio raíz como alternativa. El directorio .well-known es el directorio estándar de "recursos conocidos" definido en el RFC 8615, otros archivos estándar como robots.txt también se colocan en ubicaciones relacionadas. Segundo, debe proporcionarse a través de HTTPS, HTTP en texto plano se considera inseguro. Tercero, el Content-Type debe ser text/plain, no text/html u otros tipos. Cuarto, no hagas redireccionamientos de dominio cruzado para security.txt: si https://example.com/.well-known/security.txt redirige a https://other-domain.com/security.txt, los investigadores y herramientas automatizadas lo considerarán sospechoso. Quinto, recuerda establecer el campo Expires y actualizarlo periódicamente, un security.txt vencido se considerará información no confiable.
El campo Contact es el campo más importante en security.txt y el único campo verdaderamente indispensable (Expires también es obligatorio, pero es solo una marca de tiempo). Contact admite tres formatos de URI: mailto: para direcciones de correo, https:// para enlaces web (como páginas de formulario de reporte de seguridad), tel: para números de teléfono. Se recomienda encarecidamente proporcionar al menos un correo mailto y un enlace de formulario https: los formularios pueden prevenir el correo no deseado de bots, mientras que los correos son más convenientes para que los investigadores envíen directamente informes cifrados. Múltiples contactos se pueden listar en varias líneas, por ejemplo proporcionar simultáneamente correo del equipo de seguridad, correo del responsable de seguridad, enlaces a plataformas de terceros de vulnerabilidades, etc.
Aunque el campo Encryption es opcional, es muy importante en la práctica. Cuando los investigadores de seguridad encuentran una vulnerabilidad grave (como fuga de datos de usuarios, ejecución remota de código), no quieren absolutamente enviar los detalles de la vulnerabilidad en correos de texto plano, porque los correos pasan por múltiples servidores durante la transmisión y cualquiera de ellos puede ser espiado. El cifrado con clave pública PGP (Pretty Good Privacy) es el método estándar de la industria para comunicación segura. Solo necesitas generar un par de claves PGP, colocar la clave pública en el sitio web (por ejemplo /.well-known/pgp-key.txt) y completar esta URL en el campo Encryption. Los investigadores cifran el contenido del informe con tu clave pública y solo las personas que poseen la clave privada correspondiente pueden descifrarlo y leerlo.
El campo Policy enlaza a tu página de Política de Divulgación de Vulnerabilidades (Vulnerability Disclosure Policy, VDP), que es clave para generar confianza en los investigadores. Un buen VDP debe explicar claramente: alcance de las pruebas (qué sistemas están dentro del alcance de prueba, cuáles no), métodos de prueba permitidos (por ejemplo se permiten pruebas de inyección SQL/XSS pero se prohíbe DDoS/ingeniería social/acceso a datos de usuarios reales), tiempo de respuesta comprometido (como "confirmaremos la recepción del informe en 3 días hábiles"), si se ofrecen recompensas por vulnerabilidades, compromiso de puerto seguro legal (aclarar explícitamente que no se demandará a investigadores de buena fe que sigan las reglas), etc. Existen muchas plantillas VDP internacionales como referencia, y CISA de EE. UU. también proporciona una plantilla VDP de código abierto.
Además del contacto de seguridad en sí, security.txt tiene varios campos sorpresa. El campo Acknowledgments establece el Salón de la Fama de Seguridad (Hall of Fame), agradeciendo públicamente a los investigadores que te ayudaron a encontrar vulnerabilidades, lo cual es un reconocimiento a su trabajo y también una forma de construcción comunitaria. El campo Hiring es un diseño muy inteligente: las personas que pueden encontrar vulnerabilidades en tu sitio web son en sí mismas excelentes talentos en seguridad, y colocar enlaces de contratación en security.txt es el canal más preciso para reclutar talento en seguridad. Muchas empresas han contratado excelentes ingenieros de seguridad a través de security.txt. El campo Canonical es una consideración de seguridad, evitando que atacantes falsifiquen tu security.txt en otros dominios.
Respecto a la preocupación común por el correo no deseado, de hecho la mayoría de las organizaciones que ya han implementado security.txt informan que el aumento de correo no deseado no es significativo. Esto se debe a que: primero, los remitentes de correo no deseado generalmente no obtienen correos rastreando security.txt; segundo, se pueden usar enlaces de formulario https:// en lugar de colocar directamente correos mailto, y agregar CAPTCHA a los formularios puede interceptar completamente a los bots; tercero, los correos de seguridad dedicados (como security@) generalmente tienen filtros de correo no deseado estrictos configurados. En comparación, los informes de vulnerabilidades graves que se pierden por falta de canales de contacto de seguridad tienen un costo mucho mayor que el posible aumento de una pequeña cantidad de correo no deseado.
Este generador se construye estrictamente siguiendo el estándar RFC 9116, y todos los formatos de salida se procesan de forma normalizada: el campo Contact reconoce automáticamente los prefijos, el campo Expires usa el formato de tiempo UTC ISO 8601 estándar, Preferred-Languages se configura automáticamente según el idioma que estés usando. El contenido generado se puede copiar e implementar directamente en la ruta /.well-known/security.txt sin necesidad de modificaciones. Al mismo tiempo, todas las configuraciones se completan localmente en tu navegador y no se envían a ningún servidor: tu información de contacto de seguridad siempre se mantiene en tu dispositivo. Implementar security.txt solo toma 5 minutos, pero el canal de comunicación de seguridad que establece puede ayudarte a evitar un incidente de seguridad grave en el futuro.
