Logs con PII: el riesgo silencioso que tu auditoría de WordPress está ignorando | Drokio Blog | Drokio
PrivacidadlogsPIIWordPress
🪵Logs con PII: el riesgo silencioso que tu auditoría de WordPress está ignorando
Access logs, logs de plugins, WooCommerce logs y logs de email transaccional acumulan emails, IPs y teléfonos sin que nadie los revise. Cómo auditarlos, sanitizarlos y definir retención sin perder observabilidad.
Ahí hay tres problemas serios que tu política de privacidad probablemente no cubre:
IPs retenidas indefinidamente.
Un token de reseteo de contraseña en un log de acceso —donde cualquiera con acceso al log puede intentar usarlo.
Un email en la URL (mala práctica del dev, pero ahí está), registrado para siempre.
Los logs son el rincón de los ecommerce donde más PII se acumula sin que nadie la vea. Los devs miran la base de datos, los abogados miran la política, los auditores miran el checkout. Nadie mira los logs. Y cuando hay una brecha, los atacantes extraen en minutos lo que tardaron años en acumularse: historial completo de visitantes, tokens, emails, intentos de login, patrones de comportamiento.
Este artículo es el mapa completo de dónde se acumula PII en los logs de WordPress, cómo auditarla sin volverte loco, y cómo sanitizar sin romper la observabilidad que necesitás para debuguear y responder a incidentes.
Lo que vas a aprender
Los seis sistemas de logging que todo WordPress acumula sin configurar
Qué PII específica vive en cada tipo de log y por qué es problemática
La técnica de sanitización por tipo: truncado, hashing, redacción con regex, rotación
Cómo definir retención por tipo de log sin romper la capacidad de debuguear incidentes
Los tres plugins que más PII loguean y cómo reconfigurarlos
Un pipeline de logs anonimizado para observabilidad legítima sin acumulación de riesgo
Los seis sistemas de logging que acumulan PII en un WordPress típico
Si nunca auditaste los logs, probablemente tenés seis fuentes activas. Cada una con su formato, su ubicación, su PII y su riesgo.
1. Access logs del servidor web
Nginx, Apache o Caddy registran cada request que llega al sitio. Por defecto incluyen IP del cliente, timestamp, método + URL, código de respuesta, User-Agent, referer.
PII típica: IP del visitante, User-Agent (puede ser fingerprint), URLs con parámetros que contienen emails/IDs/tokens, referer que revela navegación previa.
Ubicación: /var/log/nginx/access.log, /var/log/apache2/access.log, o la ruta configurada por tu panel (cPanel, Plesk, Laravel Forge).
Problema mayor: rotación por defecto suele ser débil (mensual, sin límite de tamaño), y los logs rotados rara vez se borran. Encontrarás servidores con 3 años de access logs acumulados.
2. Error logs del servidor y PHP
Cuando algo rompe, el error va al log con el contexto del momento. Ese contexto a menudo incluye variables de sesión, parámetros de POST, headers.
PII típica: cualquier cosa que esté en memoria cuando ocurre el error. Contraseñas en formularios que fallaron validación, tokens de sesión, datos de checkout a medio procesar.
Ubicación: /var/log/nginx/error.log, /var/log/php_errors.log, o wp-content/debug.log si tenés WP_DEBUG_LOG activo (nunca debería estar en producción, pero lo está en el 30% de los sitios).
Problema mayor: los error logs suelen quedar accesibles vía web si la configuración del servidor falla (wp-content/debug.log público es un clásico).
3. Logs de WooCommerce
WooCommerce tiene su propio sistema de logs en wp-content/uploads/wc-logs/. Registra errores de pasarela de pago, fallos de emails, problemas con zonas de envío, deprecaciones.
PII típica: cuando un pago falla, el log puede contener el response de la pasarela con últimos 4 dígitos de tarjeta, código de autorización, email del cliente, referencia de pedido.
Ubicación: /wp-content/uploads/wc-logs/. Los archivos tienen nombres aleatorios pero predecibles (payment-gateway-stripe-YYYY-MM-DD-hash.log).
Problema mayor: por defecto son públicos si no configurás deny en el server. Vulnerabilidad recurrente.
4. Logs de emails transaccionales
Plugins como WP Mail SMTP, Fluent SMTP, Post SMTP, Easy WP SMTP. Todos ofrecen "email log" como feature popular.
PII típica: destinatario, CC, BCC, asunto, body completo del email. En pedidos incluye nombre, dirección, items comprados, total. En recuperación de contraseña incluye el token de reset completo. En suscripciones incluye el link de confirmación.
Ubicación: base de datos, tabla wp_wpms_logs o similar.
Problema mayor: el body del email es una mina de oro para un atacante. Acceso al admin = acceso a todo el historial de comunicaciones. Y los tokens de reseteo que ya caducaron siguen en el log, delatando patrones.
5. Logs de plugins de seguridad
Wordfence, iThemes Security (ahora Solid Security), Sucuri, WP Cerber. Todos registran intentos de login, cambios en archivos, accesos sospechosos, bloqueos de IP.
PII típica: IPs de atacantes y legítimos, usernames intentados (a veces los usuarios tipean su password en el campo de username), user IDs de quien hizo cambios, archivos modificados, información de sesión.
Ubicación: base de datos, tablas propias del plugin.
Problema mayor: retención típica muy larga (Wordfence conserva meses) y algunos plugins incluyen intentos de credenciales fallidas en texto plano cuando el username coincide con un password (ataques de credential stuffing mal configurados).
6. Logs de analytics y tracking
Google Analytics (hash de IP ya por defecto), Matomo auto-hospedado, Plausible, plugins internos de conversión. Si el analytics vive en tu servidor, los logs pueden acumular cookies, hashes de visitante, paths completos.
PII típica: ID de visitante persistente (pseudo-ID pero con alcance temporal largo), paths que incluyen user IDs, referers con tokens.
Ubicación: base de datos del analytics, o archivos planos si auto-hospedás.
Problema mayor: el ID de visitante cross-sesión efectivamente identifica a un usuario recurrente, aunque no sepas el nombre.
Las técnicas de sanitización
No borrás los logs —los necesitás para debuggear y responder a incidentes—. Sanitizás: reducís la PII al mínimo útil.
Truncado de IPs
Para IPv4, quitar el último octeto: 203.12.44.91 → 203.12.44.0. Mantiene el rango geográfico y de red para análisis, destruye la identificación individual.
Para IPv6, quitar los últimos 80 bits (dejar solo los primeros 48): 2001:db8:a::1234:5678:90ab → 2001:db8:a::.
Se puede aplicar al momento del logging (mejor) o como batch job que reescribe logs a cierta edad (peor, porque el log crudo existe durante ese tiempo).
Hashing con sal
Reemplazar IPs o emails por hash(valor + sal_rotada). La sal rota cada 30-90 días, así que hashes viejos no se correlacionan con nuevos. Permite detectar patrones dentro de una ventana pero no a lo largo de meses.
Usar Argon2 o SHA-256 con sal de al menos 32 bytes. Nunca MD5 o SHA-1 para este propósito.
Redacción con regex
Para logs textuales (access logs, error logs con contexto), aplicar patrones de reemplazo:
Emails: \w[\w._%+-]*@\w[\w.-]+\.\w{2,} → [EMAIL]
Números de tarjeta: \b(?:\d[ -]*?){13,19}\b → [CARD]
DNIs/CUITs comunes: patrones según país.
Tokens de sesión conocidos: parámetros como key=, token=, nonce= → [TOKEN]
La redacción puede ser destructiva (reemplazar in-place) o con mapping (guardar el valor original tokenizado en un vault separado para casos donde necesitás desandarla). Para logs de observabilidad pura, destructiva es lo correcto.
Rotación agresiva
Definir un plazo máximo y aplicarlo con cron. Propuestas típicas:
Logs de WooCommerce: 30 días, 90 si hay disputa activa.
Logs de emails: metadatos 90 días, body 7 días máximo.
Logs de plugins de seguridad: 90 días.
Logs de analytics: según lo que el producto defina, pero nunca indefinido.
Rotación implica borrado efectivo, no solo mover a otro directorio y olvidar.
Pipeline separado
Para observabilidad seria, muchos sitios mandan los logs a una stack externa (ELK, Grafana Loki, Datadog, Sumo Logic). Esa stack agrega retención y control, pero también agrega un sub-procesador con copias de PII. Tres reglas:
Sanitizar antes de enviar al pipeline, no después.
Cifrar en tránsito (TLS) y en reposo (AES-256 o equivalente).
Firmar DPA con el proveedor que incluya retención y derecho de borrado por titular.
Bóveda cifra y sanitiza tus logs automáticamente
Intercepta access logs, error logs y logs de WooCommerce antes de escribirlos a disco. Aplica truncado de IP, redacción con regex y rotación automática. Acceso controlado con cifrado en reposo.
Los plugins que más PII loguean y cómo reconfigurarlos
Tres plugins son responsables de la mayoría de los hallazgos incómodos en auditorías.
WP Mail SMTP
Por defecto, si activás el email log, guarda el body completo. El vector de ataque es que un admin comprometido tiene acceso inmediato a todas las comunicaciones históricas.
Reconfiguración:
Email Log: activado pero con "Save Content" desactivado.
Retention: 30 días máximo.
Rol con acceso al log: solo administrador principal, no administradores secundarios.
Export del log: solo manual, con justificación documentada.
Si realmente necesitás el body para debuguear, activalo temporal (1 semana), documentalo en tu log de cambios de configuración, y desactivalo cuando termines.
Wordfence
El Live Traffic de Wordfence registra cada visita con IP, User-Agent, path completo. Históricamente retuvo hasta 90 días con plan premium.
Reconfiguración:
Live Traffic: deshabilitado en producción salvo análisis específico.
Capa 3 — Pipeline externo (opcional). Enviar logs sanitizados a una stack de observabilidad con retención definida y DPA firmado.
Capa 4 — Respuesta a incidentes. Cuando hay un incidente, escalada temporal de verbosidad, retención extendida durante la investigación, sanitización antes de compartir con terceros (consultoría forense, equipo legal).
Capa 5 — Auditoría periódica. Trimestral: revisar qué se está logueando, si hay plugins nuevos agregando fuentes, si la retención se está aplicando correctamente, si hay acceso no autorizado a los logs.
Ese pipeline no es obra de un día. Es una capacidad que se construye iterativamente. Pero empezar es barato: truncar IPs en el nginx.conf y rotar los access logs a 30 días se hace en una hora.
Qué hacer con los logs viejos que ya tenés
Es probable que descubras al auditar: años de access logs, gigabytes de wc-logs, tablas de 50 millones de filas en WP Mail SMTP.
El camino correcto:
Inventario. Tamaño, fuente, contenido de muestra, edad de los más viejos.
Triage. Separar los que tienen uso operativo documentado de los que no.
Los sin uso: borrado completo, con evidencia de la acción.
Los con uso: sanitización batch (script que procesa y reescribe), seguido de rotación normal.
Documentación. Política de retención nueva, comunicada al equipo, aplicada con cron.
Verificación. 30 días después, auditar que la política se está aplicando.
El pasado no te exime —si te auditan mañana, los logs viejos son evidencia de acumulación—. Pero una acción correctiva documentada (fecha, qué se hizo, por qué) convierte el hallazgo en "atendido" antes de que se vuelva problema.
Cierre
Los logs son el barrio olvidado del WordPress. Son infraestructura, no feature de cliente. Nadie los ve, nadie los audita, nadie los menciona en la política de privacidad. Y ahí es donde se acumulan años de PII que, el día de una brecha, salen en segundos.
Sanitizar logs no rompe la observabilidad —la mejora—. Un log con IPs truncadas y tokens redactados es más seguro y sigue siendo útil para detectar ataques, debuguear errores y responder a incidentes. Lo que se pierde es capacidad de identificar visitantes individuales, que es exactamente lo que no deberías poder hacer sin base legal.
La auditoría de logs es el ejercicio más barato de privacidad con mejor retorno. Una tarde de trabajo cerrando el nginx.conf, el WP Mail SMTP y el wc-logs puede reducir el blast radius de una brecha futura en un orden de magnitud. Es inversión que se paga sola la primera vez que alguien intenta explotarte.
Preguntas frecuentes
¿Un access log de nginx con IPs cuenta como procesamiento de PII?
Sí. Bajo GDPR y la mayoría de leyes LATAM, una IP es dato personal porque permite identificar indirectamente al titular (vía el ISP con orden judicial, o por cruce con otros datos). Tenés que justificar la retención, definir plazo, y permitir ejercicio de derechos sobre esos logs.
¿Cuál es el plazo típico de retención de access logs defendible?
Entre 6 y 12 meses para el log crudo con IP, justificado por seguridad (detección de ataques, análisis post-incidente). A partir de ahí: anonimizar (truncar últimos octetos de IPv4, hashear con sal) y conservar solo lo agregado. Retener IPs 5 años sin justificación operativa es indefendible.
Mi WP Mail SMTP guarda el contenido de los correos enviados. ¿Eso es un problema?
Grande. Los emails transaccionales contienen PII (nombre, dirección, items comprados) y a veces tokens de recuperación de contraseña. Si tu log de envío guarda el body completo, un acceso no autorizado al admin da acceso a todo el historial de comunicaciones. Configurá el plugin para guardar solo metadatos (destinatario, asunto, estado) o aplicá rotación agresiva (máximo 30 días).
¿Puedo usar logs con PII para análisis si los anonimizo antes?
Sí, pero la anonimización tiene que ser real. Hashear la IP con sal secreta rotada, truncar últimos octetos, agrupar por rango horario en lugar de timestamp exacto. Si podés re-identificar al titular combinando el log anonimizado con otro log que tengas, no está realmente anonimizado.
¿Los logs del plugin de seguridad (Wordfence, iThemes) son diferentes?
Conceptualmente sí, porque la base legal es más fuerte (seguridad del sistema). Pero eso no los exime: siguen conteniendo PII (IPs, usernames intentados, a veces contraseñas en intentos fallidos si el plugin las registra). Limitá la retención a 90 días, sanitizá antes de exportar, y controlá el acceso al admin con la misma rigurosidad que la base principal.
¿Qué hago con logs viejos que ya tengo llenos de PII sin política?
Empezá por inventariar: qué archivos, qué tamaño, qué contienen. Si la mayoría son antiguos y sin uso documentado, borralos. Si tienen valor operativo, anonimizalos con un script de una sola pasada (truncar IPs, hashear emails, redactar tokens) y archivalos con nueva retención. El pasado no te exime, pero lo importante es la acción correctiva documentada.
Producto mencionado
🏦
Bóveda
Señuelos de datos que delatan el robo
Señuelos (canary tokens) de datos que delatan un intento de exfiltración en el acto, con score de disuasión y patrones de atacante corroborados por la flota. $19/mes.
Derechos ARCO y derecho al olvido en WordPress: cómo implementarlos sin romper tu contabilidad
Guía técnica y legal para procesar solicitudes de acceso, rectificación, cancelación y oposición en WordPress/WooCommerce. Qué borrar, qué retener por obligación legal, cómo responder en plazo y dejar evidencia firmada.
