Qué es realmente security.txt
security.txt es un archivo de texto plano, definido en la RFC 9116, que le indica a cualquiera que encuentre una vulnerabilidad de seguridad en tu sitio exactamente cómo reportarla. Vive en una ubicación predecible —/.well-known/security.txt— para que los investigadores de seguridad y los escáneres automatizados no tengan que rebuscar en tu página de contacto ni adivinar una dirección de correo.
Un ejemplo mínimo se ve así:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: es
Eso es todo el formato: un pequeño conjunto de campos en texto plano, cada uno en su propia línea. Sin JSON, sin XML, nada complicado.
Por qué esto importa más allá de "estaría bien tenerlo"
Sin un archivo security.txt, un investigador que encuentre una vulnerabilidad en tu sitio WordPress tiene opciones limitadas: rebuscar en tu formulario de contacto, adivinar una dirección de correo, o —si no encuentra nada razonable— publicar la vulnerabilidad públicamente sin darte la oportunidad de arreglarla primero. Ninguno de esos resultados es bueno para ti.
También hay un ángulo regulatorio. El Cyber Resilience Act de la UE, que se aplica a productos con elementos digitales vendidos en la UE, exige a los fabricantes tener un proceso documentado de gestión y divulgación de vulnerabilidades. security.txt no es todo el requisito de cumplimiento, pero es la forma estándar y esperada de hacer ese proceso detectable públicamente. Si tu sitio WordPress atiende a usuarios de la UE o vende productos digitales, tener uno es un paso pequeño y de bajo esfuerzo hacia esa expectativa más amplia.
Qué campos pertenecen realmente al archivo
La RFC define varios campos, no todos requeridos. Esto es lo que hace cada uno:
Contact (requerido, al menos uno): Cómo contactarte. Puede ser un correo (mailto:), una URL a un formulario de reporte, o ambos. Puedes listar varias líneas Contact si tienes más de un canal de reporte.
Expires (requerido): Una marca de tiempo ISO 8601. Esto te obliga a revisar y reconfirmar el archivo periódicamente —un security.txt con años de antigüedad y datos de contacto obsoletos es discutiblemente peor que no tener ninguno. Ponlo en algo realista, como un año vista, y actualízalo cuando caduque.
Encryption (opcional): Un enlace a una clave PGP si quieres que los investigadores cifren los reportes con detalles sensibles antes de enviarlos.
Acknowledgments (opcional): Un enlace a una página que reconoce a los investigadores que han reportado problemas de forma responsable —un pequeño incentivo que algunos investigadores buscan específicamente antes de decidir reportar en lugar de divulgar públicamente.
Preferred-Languages (opcional): En qué idiomas puedes leer los reportes.
Canonical (opcional): La URL autorizada del propio archivo, útil si tu sitio es accesible mediante varios dominios.
Policy (opcional): Un enlace a tu política completa de divulgación de vulnerabilidades —el documento detallado que describe el alcance, los tiempos de respuesta esperados, y qué pueden esperar los investigadores de ti.
Añadir security.txt a WordPress
Como la estructura de "Ajustes → Enlaces permanentes" de WordPress gestiona la mayoría de URLs a través de PHP, conseguir que un archivo estático viva en /.well-known/security.txt necesita uno de estos dos enfoques:
Opción A — Subir el archivo directamente vía FTP/gestor de archivos. Crea un archivo llamado security.txt con el contenido anterior, y súbelo al directorio .well-known en la raíz web de tu sitio (crea el directorio si no existe). Esto funciona en prácticamente cualquier hosting y no depende de WordPress en absoluto, lo cual es en realidad una ventaja —seguirá funcionando incluso si cambias de tema o de plugins.
Opción B — Usar un plugin que lo gestione por ti. Mantener manualmente un archivo estático significa recordar actualizar el campo Expires cada año y mantener los datos de contacto sincronizados si cambian. Erdo CRA Compliance genera y sirve un archivo security.txt como parte de su escaneo de cumplimiento de la UE más amplio, junto con la otra documentación (política de divulgación de vulnerabilidades, SBOM) que espera el Cyber Resilience Act —así que se mantiene en un solo lugar en lugar de como un archivo estático olvidado de hace tres años.
Errores comunes
Algunas cosas que merece la pena comprobar una vez añadido el archivo:
- Olvidar actualizar Expires. Un security.txt caducado señala más descuido que no tener ninguno. Pon un recordatorio en el calendario, o usa una herramienta que gestione esto por ti.
- Usar una dirección de contacto que nadie supervisa. Si security@tudominio.com llega a una bandeja que nadie revisa, has resuelto el problema de detectabilidad y creado un nuevo callejón sin salida.
- Ponerlo solo en la raíz del dominio. /.well-known/security.txt es la ubicación estándar actual. Un /security.txt a nivel raíz está permitido como respaldo para rastreadores antiguos, pero no confíes solo en él.
- Tratarlo como toda la historia de cumplimiento. security.txt hace detectable tu canal de divulgación; no sustituye tener un proceso de triaje real para cuando llega un reporte.
Resumiendo
security.txt es una solución de cinco minutos con un beneficio desproporcionado: convierte "encontré un fallo en tu sitio, ¿y ahora qué?" de un callejón sin salida en un proceso documentado. Ya sea que lo añadas manualmente como archivo estático o dejes que una herramienta de cumplimiento lo mantenga junto a tu otra documentación de la UE, es una de las prácticas de seguridad de menor esfuerzo y mayor impacto que un sitio WordPress puede adoptar.