Alguien encuentra una falla en tu sitio y quiere avisarte. Busca a quién escribir, no encuentra nada y termina mandando un mensaje por LinkedIn a alguien de marketing que lo toma por spam. Un archivo de texto de cuatro líneas resuelve ese escenario.
Qué es
security.txt es un archivo de texto plano definido en el RFC 9116. Se publica en una ruta conocida de tu dominio y declara cómo reportarte un problema de seguridad. Misma idea que robots.txt: un lugar predecible donde buscar.
Por qué conviene
El costo de no tenerlo no es que nadie te reporte. Es que quien encuentra algo elija peor.
Te escribe a un correo genérico que nadie lee, se lo cuenta a un conocido tuyo o lo publica. Un canal declarado convierte un hallazgo casual en un aviso que llega a la persona correcta.
Hay además un efecto que se subestima: quien evalúa tu postura de seguridad desde afuera nota primero la ausencia de un canal de reporte.
Dónde va
En https://tudominio.cl/.well-known/security.txt, servido como text/plain y por HTTPS. Puedes dejar una copia en la raíz del dominio por compatibilidad, pero la ruta canónica es la primera.
Qué lleva
Dos campos obligatorios y cinco opcionales.
ContactObligatorioCómo avisarte: un correo, un formulario o ambos, en orden de preferencia.
ExpiresObligatorioHasta cuándo vale el archivo. Existe para que uno abandonado se note.
Preferred-LanguagesOpcionalEn qué idiomas atiendes. En Chile, español e inglés evitan fricción.
CanonicalOpcionalLa URL donde vive el archivo, para detectar copias en dominios ajenos.
EncryptionOpcionalUna clave pública, si puedes recibir reportes cifrados.
PolicyOpcionalLa página con tu política de divulgación.
AcknowledgmentsOpcionalDónde reconoces a quienes te han reportado.
Arma el tuyo
Cambia los datos y copia el archivo. Todo ocurre en tu navegador; no se envía nada.
Contact: mailto:seguridad@tuempresa.clExpires: AAAA-MM-DDT00:00:00.000ZPreferred-Languages: es, enCanonical: https://tuempresa.cl/.well-known/security.txt- Contact tiene un correo válido
- Buzón del dominio de la empresa
- Expires vence en menos de un año, como recomienda el RFC
- Idiomas declarados: es, en
Cuatro líneas bastan. Si tienes una página que explique cómo tratas los reportes, agrega la línea Policy.
Errores que se repiten
- Sin Expires, o vencido
Es el campo que distingue un canal vivo de uno olvidado.
- Un correo personal
La persona cambia de rol o de empresa y el canal muere sin que nadie lo note. Usa un buzón del área con más de un responsable.
- Un buzón que nadie atiende
El peor caso: prometiste un canal y no respondes. Quien reportó de buena fe queda sin respuesta, y ahí es cuando alguien decide publicar.
- Publicarlo sin avisar adentro
Define antes quién revisa los reportes, en qué plazo se responde y cómo escala uno grave.
Lo que no es
Publicar un security.txt no crea un programa de recompensas ni te obliga a pagar por lo que te reporten. Tampoco autoriza a nadie a probar tus sistemas: declarar un canal de reporte y autorizar una revisión son dos cosas distintas, y conviene que tu política lo diga con esas palabras.
Cuidado con el safe harbor
Muchas políticas de divulgación incluyen un compromiso de no perseguir legalmente a quien reporte de buena fe. Es una buena práctica y es texto legal: define obligaciones tuyas y expectativas de terceros. Redáctala con tu abogado en vez de copiarla de otra empresa. Nuestra política de recepción de reportes delimita su alcance y no incluye una cláusula de puerto seguro.
Después de publicarlo
0 de 3
Es la mejora de seguridad más barata que vas a hacer este trimestre, siempre que alguien se haga cargo del buzón.
Relacionado
Si estás evaluando una revisión externa, sirve saber qué exigir en una propuesta y qué revisamos y qué no.