Un security.txt útil debe superar dos comprobaciones: el servidor entrega el fichero correcto y el canal de contacto conduce a alguien que puede gestionar el aviso. Subir un documento y olvidarlo deja fuera la segunda mitad del trabajo.

Esta guía propone una implantación pequeña y mantenible, con comprobaciones que puedes incorporar al trabajo habitual del equipo.

1. Decide quién recibirá los avisos

Antes de crear el fichero, elige un buzón o formulario que tenga una persona responsable. Para un equipo pequeño, un alias dedicado puede servir, siempre que llegue a una bandeja atendida y exista un sustituto durante vacaciones o ausencias.

Haz una prueba desde una cuenta externa y confirma la recepción. Comprueba también que las respuestas salen correctamente. Un correo que acepta mensajes pero acaba en una carpeta que nadie revisa deja el problema a medias. Documenta internamente quién clasifica el aviso y cómo lo traslada a la persona que puede investigarlo.

2. Crea un ejemplo sencillo

La web del proyecto explica los campos básicos: Contact identifica el canal de comunicación y Expires establece la caducidad. Ambos son obligatorios. Los idiomas y la dirección canónica son opcionales.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:59:59Z
Preferred-Languages: es, en
Canonical: https://example.com/.well-known/security.txt

example.com es un dominio reservado para documentación. Sustituye el dominio y el correo por valores que controles; el ejemplo no describe un servicio operativo. Ajusta también los idiomas a los que realmente podéis atender.

La fecha propuesta está pensada para una implantación en octubre de 2026. Al copiarla, elige una nueva fecha futura: el RFC recomienda menos de un año de vigencia. Debe existir una sola línea Expires. Una vez superada, la información se considera obsoleta y no debería utilizarse.

3. Publica el fichero en la ruta correcta

Para una web, la ubicación definida en el RFC 9116 es https://example.com/.well-known/security.txt, servido por HTTPS como texto plano UTF-8. La cabecera adecuada es Content-Type: text/plain; charset=utf-8.

Inclúyelo en el mismo proceso de despliegue que el resto de los recursos públicos. Así será más fácil revisar sus cambios y evitar que una actualización lo elimine. Si utilizas un CMS, comprueba que su enrutador no convierte esa dirección en una página del blog.

Revisa cada dominio y subdominio que administres: el alcance del fichero no se hereda automáticamente entre ellos. Si incluyes Canonical, haz que corresponda a la dirección real desde la que se consulta.

4. Comprueba lo que recibe un visitante

Abre la dirección pública y revisa también su respuesta HTTP. Este comando es un ejemplo: sustituye el dominio por el de tu propia web antes de utilizarlo.

curl -sS -i --max-time 15 'https://example.com/.well-known/security.txt'

Las opciones muestran cabeceras y contenido, conservan los mensajes de error y limitan la operación a quince segundos, según el manual de curl. El comando permite inspeccionar la respuesta; no valida por sí solo toda la especificación.

  • Si recibes un 404, revisa la ruta pública y el despliegue.
  • Si aparece HTML, comprueba el enrutador, la página de error y las reglas del servidor.
  • Si hay una redirección, inspecciona su destino y confirma que termina en el fichero previsto.
  • Si aparece una versión antigua, revisa la caché del servidor o de la CDN.

Un estado 200 no basta: mira el contenido, el tipo de respuesta, el contacto y la fecha. Conviene repetir esta comprobación después de cambiar el alojamiento o las reglas de rutas.

5. Convierte la caducidad en una tarea real

Una propuesta práctica es revisar el fichero cada trimestre y preparar dos avisos: uno 30 días antes del vencimiento y otro 7 días antes. Son intervalos de trabajo sugeridos, no una periodicidad impuesta por el RFC.

Al renovarlo, verifica primero el buzón y los enlaces. Después actualiza la fecha y comprueba la versión pública. Si solo se retrasa Expires automáticamente, un contacto abandonado podría parecer actualizado. Deja la responsabilidad asignada en el gestor de tareas y registra cualquier cambio de equipo o de proveedor.

6. Mantén claras sus funciones

Publicar este fichero facilita recibir avisos; no corrige vulnerabilidades ni garantiza que la web sea segura. Tampoco concede permiso para realizar pruebas, como aclara el RFC 9116. Una implantación útil combina una dirección fácil de encontrar, un responsable accesible y una rutina de revisión que sobreviva al primer despliegue.

Referencias