El plugin acaba de sincronizar cientos de contactos de WooCommerce con tu plataforma de email marketing. La campaña sale sin errores, pero nadie ha revisado qué datos viajan, quién conserva el token de acceso o si un webhook podría aceptar peticiones falsas. Un permiso excesivo o una clave expuesta bastan para convertir una automatización útil en un incidente de seguridad y privacidad.
La Seguridad para integraciones de email marketing en WordPress no consiste solo en instalar un plugin: exige limitar permisos, proteger tokens y webhooks, cifrar datos y documentar el RGPD. Antes de sincronizar contactos o pedidos, revisa el flujo completo de datos, configura SPF, DKIM y DMARC, y prepara un plan para revocar accesos e incidentes.
Antes de conectar, comprueba si tu flujo es seguro
Una conexión entre WordPress y una plataforma de email solo es segura si sabes qué datos salen, qué sistema los recibe, con qué permiso y para qué fin.
Checklist antes de activar la conexión
Antes de activar una integración, deja por escrito el origen del dato, su destino, la finalidad y el responsable de cada paso. Si un contacto pasa de un formulario de WordPress a Brevo y luego a un CRM, deben quedar identificados los tres sistemas.
- Datos mínimos: envía email y preferencias si bastan; no copies teléfono, dirección o notas internas por defecto.
- Conexión cifrada: comprueba HTTPS válido en la web, los formularios y la URL que recibe eventos.
- Plugin revisado: confirma actualizaciones recientes, desarrollador conocido, permisos pedidos y compatibilidad con tu versión de WordPress.
- Contrato de datos: localiza el acuerdo de procesamiento de datos, también llamado DPA, de cada proveedor.
- Recuperación: conserva copias de seguridad cifradas y prueba cómo desconectar el servicio sin bloquear la web.
Señales de una integración insegura
Una clave pegada en functions.php, en un correo o en un repositorio Git es una exposición, aunque el repositorio sea privado. Una copia de seguridad, una captura de pantalla o un antiguo colaborador pueden acabar revelándola.
Antes de sincronizar el primer contacto: define qué token usa cada conexión, quién puede revocarlo y dónde queda el registro de consentimiento. Si no puedes responder esas tres preguntas, la integración aún no está lista.
Los riesgos cambian según el sistema conectado
El riesgo no es igual en un formulario que solo recoge un email que en WooCommerce, donde hay pedidos, direcciones y hábitos de compra.
Un formulario de suscripción debería pedir entre 1 y 3 datos: correo, nombre si lo necesitas y preferencia de contenidos. Cada campo extra aumenta el daño posible ante una fuga y obliga a explicar mejor por qué lo recoges.
WooCommerce, CRM y automatizadores
WooCommerce requiere separar datos de servicio, como dirección para entregar un pedido, de datos para marketing. Un cliente que compra no acepta automáticamente cualquier campaña comercial; la LSSI-CE y la normativa de privacidad fijan condiciones concretas para esas comunicaciones.
| Integración | Datos que conviene enviar | Riesgo principal | Control mínimo |
|---|
| Formulario WordPress | Email y preferencia | Altas falsas o token expuesto | Doble opt-in y token limitado |
| WooCommerce | Producto, fecha y permiso comercial | Exportar facturación completa | Campos selectivos y retención |
| CRM y automatizador | Identificador y evento necesario | Replicar datos entre servicios | Mapa de subencargados y logs |
| API a medida | Solo la carga definida | Errores de programación | Pruebas, firma y control de acceso |
La arquitectura elegida determina el nivel de exposición. Un plugin autocontenido reduce el número de proveedores, pero concentra la seguridad en WordPress y exige mantener el código, los roles y las actualizaciones bajo control. Un conector oficial suele simplificar la autenticación mediante OAuth 2.0 y facilita la revocación de tokens de acceso, aunque debe revisarse qué permisos solicita. Una plataforma externa puede aportar automatizaciones y analítica avanzadas, pero añade otro tratamiento de datos y posibles subencargados.
En los tres casos, aplica permisos mínimos: usa una credencial distinta por entorno, limita quién puede modificar la conexión y documenta qué datos entran y salen de cada componente.
Zapier, Make y herramientas similares no deben tratarse como un simple puente técnico. Cada escenario puede conservar el historial de ejecuciones, campos recibidos, errores y credenciales conectadas, por lo que amplía la superficie de la protección de datos de suscriptores. Configura filtros antes de enviar información, excluye dirección, NIF, notas de pedido y otros campos que no sean imprescindibles, y revisa cuánto tiempo se guardan los logs.
Utiliza conexiones HTTPS, cuentas de servicio separadas y alertas ante cambios de escenarios. Si la herramienta recibe eventos, aplica los mismos controles de webhooks seguros: validación de firma cuando esté disponible, identificadores únicos e idempotencia para que un reintento no genere altas, bajas o campañas duplicadas.
Usa tokens mínimos y protege los webhooks
Una API segura no usa una única credencial con control total para todos los plugins y entornos.
OAuth 2.0 frente a clave API
OAuth 2.0 suele ser preferible cuando Mailchimp, HubSpot, ActiveCampaign o el CRM ofrecen permisos delimitados y renovación controlada. La clave API es más simple, pero solo resulta aceptable si el proveedor permite reducir sus permisos o aislarla por cuenta y entorno.
| Método | Caducidad habitual | Revocación | Uso recomendado |
|---|
| OAuth 2.0 | Entre minutos y horas para el token de acceso | Desde el proveedor o usuario | Apps con permisos delegados |
| Clave API limitada | Hasta rotación manual o fecha fijada | Desde el panel del proveedor | Conector técnico aislado |
| Clave maestra | Variable | Afecta a toda la cuenta | Evitar en WordPress |
Webhooks: firma y control de duplicados
Un webhook es un aviso automático que un servicio envía a otro cuando pasa algo, por ejemplo una baja o un pedido pagado. Debe entrar por HTTPS y validarse con la firma criptográfica del proveedor, una comprobación matemática que confirma que el aviso no ha sido fabricado por un tercero.
Recorrido seguro de un evento de suscripción
Formulario HTTPS→Token limitado→Doble opt-in→Webhook firmado→Log e ID único
Si falla la firma o se repite el ID, el sistema no debe crear, modificar ni borrar contactos.
Mapea los datos y prueba el consentimiento RGPD
El RGPD no se resuelve con una casilla bajo el formulario: exige demostrar qué datos se tratan, con qué base legal, dónde se alojan y durante cuánto tiempo.
Consentimiento granular y bajas reales
Una persona puede aceptar una newsletter y no aceptar perfilado comercial basado en compras. Separa finalidades, evita casillas marcadas de antemano y permite retirar el permiso con la misma facilidad con la que se dio.
Retención, derechos y proveedores
Define plazos realistas para leads que no avanzan y suscriptores inactivos, por ejemplo entre 12 y 24 meses si no existe otra relación que justifique conservarlos. El plazo concreto depende de la finalidad, pero no debe mantenerse una lista indefinidamente por comodidad.
Una integración legal no es la que recoge más casillas, sino la que puede probar qué permiso obtuvo, qué dato envió y cuándo lo borró.
El cumplimiento RGPD debe mantenerse cuando el dato cambia de plataforma. Identifica quién es responsable del tratamiento, qué proveedores actúan como encargados y qué subencargados intervienen en el envío, CRM, analítica o automatización; comprueba además que el DPA cubra esos servicios. Si hay alojamiento o acceso desde fuera del Espacio Económico Europeo, verifica el mecanismo de transferencia aplicable y la información facilitada en la política de privacidad. Prueba el recorrido completo de los derechos: una baja debe detener los envíos en todos los sistemas, y una solicitud de acceso o supresión debe localizar los registros sincronizados.
El doble opt-in y el consentimiento comercial solo son útiles si su prueba también se conserva y puede recuperarse.
Autentica el dominio antes de escalar tus envíos
SPF, DKIM y DMARC protegen el dominio de envío y mejoran la capacidad de los receptores para distinguir un mensaje legítimo de una suplantación.
SPF y DKIM sin errores habituales
Un dominio debe tener un único registro SPF, aunque incluya varios proveedores autorizados. Los registros SPF duplicados invalidan la comprobación, y superar 10 consultas DNS también puede hacer que falle.
DMARC empieza en modo observación
DMARC con p=none no bloquea correos, pero permite recibir informes y detectar envíos olvidados. Mantén la observación al menos entre 2 y 4 semanas, según el volumen, para cubrir campañas, facturas y automatizaciones menos frecuentes.
Audita accesos y responde a incidentes sin demora
Una integración sigue siendo segura si se audita cada trimestre y siempre que cambien personas, plugins, dominio, proveedor o automatizaciones.
Si un token queda expuesto
Revoca el token de inmediato desde el proveedor, crea otro con menos permisos y revisa los logs desde la última actividad legítima. Después, busca la credencial en código, copias, tickets, automatizadores y repositorios para eliminar todas las copias.
Si se envía una campaña fraudulenta
Pausa automatizaciones y campañas, cambia accesos y revisa reglas de reenvío, remitentes autorizados y usuarios con permisos de envío. Informa a los destinatarios solo cuando sea necesario y con datos claros: qué ocurrió, qué correo deben ignorar y qué no deben facilitar.
Dudas habituales
¿Necesito OAuth 2.0 para conectar WordPress?
No siempre, pero es preferible cuando el proveedor permite permisos delegados y tokens revocables. Una clave API limitada puede servir para un formulario simple si no da acceso total a listas, campañas o exportaciones.
¿Dónde guardo la clave API en WordPress?
Guárdala fuera del código público, mediante variables de entorno, configuración segura del servidor o un gestor de secretos. No la dejes en functions.php, capturas, tickets ni repositorios Git, aunque sean privados.
Envía solo los datos necesarios para una finalidad definida, como email, producto comprado y permiso comercial. Dirección, NIF, notas de pedido o teléfono no deben sincronizarse por defecto para una newsletter.
¿DMARC puede bloquear correos válidos?
Sí, si pasas a quarantine o reject sin revisar todos los emisores. Mantén p=none entre 2 y 4 semanas y corrige SPF o DKIM antes de endurecer la política.
¿Un webhook necesita una URL secreta?
Una URL poco previsible ayuda, pero no protege por sí sola. El webhook debe usar HTTPS, validar la firma del proveedor y rechazar eventos duplicados mediante un identificador único.
Debes valorar el riesgo de inmediato y documentar el incidente aunque no siempre sea notificable. Si existe riesgo para los derechos de las personas, el RGPD fija un plazo máximo de 72 horas para notificar a la autoridad competente.
Esta revisión no es prioritaria si tu sitio no capta datos personales, no conecta WordPress con servicios externos y no hace envíos. Será necesaria en cuanto actives formularios, newsletters, pedidos online, CRM o automatizaciones, aunque el volumen inicial sea pequeño.
El siguiente paso es reducir lo que conectas
La decisión más segura es conectar primero el flujo más pequeño que cumpla tu objetivo: menos campos, un token propio, doble opt-in, webhook firmado y registros revisables.
