Security.txt: El buzón para informes de errores que olvidó

Imagínese: un hacker ético encuentra en su servidor un archivo .env abierto o una vulnerabilidad crítica. No quiere atacarle — quiere ayudar. Entra en el sitio, busca contactos y… se topa con una pared. El formulario de contacto pide «número de pedido», el chatbot ofrece «elegir categoría de la consulta», y el teléfono de soporte está ocupado.

Al final el investigador o bien abandona el asunto (y el agujero queda), o lo publica públicamente, creando una crisis de reputación de la nada.

Para evitar esto, se adoptó el estándar RFC 9116 — el archivo security.txt. Es una manera sencilla de decir oficialmente al mundo: «Если вы нашли проблему, пишите сюда, мы вас услышим».

¿Qué contiene?

El archivo debe ubicarse en /.well-known/security.txt. Es un texto en formato UTF-8, donde cada línea es una directiva independiente.

• Contact (obligatorio): Enlace a un email o formulario. Es importante usar el formato URI. Se permiten varios contactos.
  • Contact: mailto:security@example.com
  • Contact: https://example.com/security-form
• Expires (obligatorio): Fecha de caducidad del archivo. Según el estándar, los datos no deben considerarse válidos indefinidamente. Se recomienda actualizarlo una vez al año. Formato ISO 8601 (por ejemplo, 2027-01-01T00:00:00Z).
• Encryption: Enlace a su clave pública PGP. Es una buena práctica — da la posibilidad de cifrar el informe, para que los detalles de la vulnerabilidad no se intercepten en tránsito.
• Preferred-Languages: Lista de idiomas en los que a su equipo le resulta más cómodo leer los informes (por ejemplo, ru, en).
• Acknowledgments: Enlace a la página de «Salón de la fama». Un detalle que motiva mucho a los investigadores — un simple «gracias» público por el bug encontrado.
• Policy: Probablemente el campo más importante. Es el enlace a su política de divulgación (VDP).

Vulnerability Disclosure Policy (VDP): Cómo no asustar a la gente

El campo Policy dirige a una página donde describe las reglas del juego. El error principal aquí es convertir la página en un seco documento legal que prohíbe todo.

Una buena política debe responder a tres preguntas:

1. ¿Qué se puede probar? (Scope)

Si el ámbito (scope) es difuso — el investigador o no le escribe, o se arriesga. Indique claramente los dominios: example.com, api.example.com. Excluya explícitamente lo que no se debe tocar: staging.example.com, paneles de administración o integraciones de terceros (Stripe, Cloudflare).

2. ¿Qué está prohibido? (Rules of Engagement)

Establezca límites. Básicamente esto incluye prohibir:

• Ataques DoS / DDoS.
• Ingeniería social contra empleados.
• Acceder a datos de terceros o eliminarlos.

3. ¿Qué promete usted a cambio? (Safe Harbor)

Este es el elemento clave de la confianza. Debe declarar claramente: «No iniciaremos acciones legales si usted actúa conforme a esta política y reporta la vulnerabilidad de forma responsable».

Consejo: Escriba en lenguaje humano. La frase «Apreciamos su contribución y nos comprometemos a responder al informe en un plazo de 48 horas» funciona mucho mejor que una renuncia de responsabilidad de diez páginas.

Herramienta: securitytxt.org

Medir manualmente el formato de la fecha en ISO 8601 o comprobar la sintaxis es una pérdida de tiempo. Para eso existe el servicio securitytxt.org.

Es un generador extremadamente sencillo: rellena los campos, el servicio los valida según el estándar y entrega el texto listo. Allí también puede preparar una firma digital (Cleartext Signature) para garantizar la autenticidad del archivo.

Implementación técnica

Crear el archivo es solo la mitad del trabajo. Hay que hacer que el servidor lo entregue con los encabezados correctos.

Configuración en Caddy

En Caddy puede servir el archivo directamente en la configuración:

example.com {
    handle_path /.well-known/security.txt {
        header Content-Type "text/plain; charset=utf-8"
        respond "Contact: mailto:security@example.com
Expires: 2027-03-30T10:00:00Z
Policy: https://example.com/security-policy
Preferred-Languages: ru, en"
    }
}

Automatización con Ansible

Si tiene una flota de una decena de servidores, lo más sencillo es desplegar este archivo con una sola tarea:

- name: Ensure .well-known directory exists
  file:
    path: /var/www/html/.well-known
    state: directory
    mode: '0755'

- name: Deploy security.txt to all web nodes
  copy:
    dest: /var/www/html/.well-known/security.txt
    content: |
      Contact: mailto:security@example.com
      Expires: 2027-12-31T23:59:59Z
      Policy: https://example.com/security-policy
      Preferred-Languages: ru, en
    mode: '0644'

Resumen

Security.txt no es una «protección contra el hacking». Es un seguro para no ser la última parte en enterarse de una vulnerabilidad crítica. Configurarlo lleva 10 minutos, pero cambia su relación con la comunidad de seguridad de «enemigos e infractores» a «socios».

Es una norma de buena práctica para cualquier proyecto serio en 2026.