Imagina que alguien que sabe de seguridad encuentra un problema en tu sitio: un archivo de respaldo descargable, un formulario que expone datos. Quiere avisarte, pero en tu web solo hay un formulario de contacto comercial. Lo más probable es que desista.
security.txt es un estándar (el RFC 9116) que resuelve eso: un archivo de texto en una ubicación fija que dice cómo reportar problemas de seguridad de tu sitio.
Dónde va
Siempre en la misma dirección:
https://tudominio.cl/.well-known/security.txtLa carpeta .well-known (con el punto al inicio) va en la raíz del sitio, junto a wp-config.php. Si usas certificados de Let’s Encrypt, probablemente ya existe.
Qué lleva
Un ejemplo completo para un sitio WordPress:
Contact: mailto:[email protected]
Expires: 2027-10-31T03:00:00.000Z
Preferred-Languages: es, en
Canonical: https://tudominio.cl/.well-known/security.txt
Policy: https://tudominio.cl/politica-de-seguridad/- Contact (obligatorio): un correo o una URL de formulario. Puedes poner más de una línea.
- Expires (obligatorio): la fecha en que el archivo deja de ser válido, en formato ISO. Recomendado: menos de un año. Así te obligas a revisarlo.
- Preferred-Languages: los idiomas en que prefieres recibir reportes.
- Canonical: la dirección oficial del archivo.
- Policy: un enlace a una página con tu política de reportes (opcional, pero muy recomendable).
Usa un correo dedicado (seguridad@ o security@), no tu correo personal. Así puedes filtrarlo, compartirlo con quien mantiene el sitio y cambiar el destino sin tocar el archivo.
Cómo crearlo
Con el Administrador de archivos de cPanel
- Ve a
public_html. Activa Mostrar archivos ocultos en la configuración, para ver las carpetas con punto. - Si no existe
.well-known, créala. - Dentro, crea un archivo
security.txtcon el contenido de arriba (adaptado). - Comprueba que abre en
https://tudominio.cl/.well-known/security.txt.
Con WP-CLI o por terminal
mkdir -p .well-known && nano .well-known/security.txtSi al abrir la dirección ves un error 404 de WordPress, revisa que el archivo esté en la carpeta correcta y que no haya una regla en el .htaccess o en un plugin de seguridad que bloquee .well-known. Esa carpeta debe ser accesible.
La página de política: evita a los cazarrecompensas falsos
Publicar un correo de seguridad atrae reportes valiosos, pero también a los cazarrecompensas falsos: personas que envían reportes automáticos sin importancia («falta una cabecera», «el sitio muestra la versión de WordPress») exigiendo un pago.
Por eso conviene una página de política breve. Por ejemplo:
- Qué está dentro del alcance (este sitio y sus subdominios).
- Qué no se considera vulnerabilidad: reportes de escáneres automáticos sin una prueba de impacto real, cabeceras de seguridad opcionales, enumeración de usuarios, ausencia de límites de velocidad sin explotación demostrada.
- Que no ofreces recompensas económicas (si es el caso), pero sí agradecimiento público si la persona lo desea.
- Que respondes en un plazo razonable (por ejemplo, 5 días hábiles).
- Que pides no publicar el problema hasta que esté corregido.
Con eso, los reportes que lleguen serán menos y de mejor calidad.
Revisa la fecha cada año
Pon un recordatorio en tu calendario una semana antes de la fecha de Expires para actualizarla. Un archivo vencido indica que nadie lo mantiene.
¿Ya tienes un security.txt? Comparte en el foro cómo redactaste tu política y te damos ideas para mejorarla.
