Por qué el papeleo solo no te protege
Muchas empresas tratan el cumplimiento del RGPD como una carpeta. Conseguir el DPA firmado por cada proveedor, archivarlo, listo. La carpeta es real y la necesitas, pero no es lo que detiene un ataque.
El Artículo 32 del RGPD pide “medidas técnicas y organizativas apropiadas”. La palabra técnicas importa. Significa configuración real en tu web, no contratos sobre configuración. Si tu proveedor tiene un DPA firmado pero un script hackeado en tu página de pago lee los números de tarjeta de tus clientes, el contrato no deshace lo ocurrido.
Una manera útil de verlo: el DPA es tu cobertura legal si todos hicieron su trabajo. La configuración de tu sitio es lo que evita que llegue el mal día.
Qué miran ahora los auditores
Las resoluciones recientes muestran que la AEPD ha dejado de aceptar el “no sabíamos que esto se podía hackear”. Cuando auditan, hacen tres preguntas:
- ¿Comprobaste a tu proveedor antes de integrarlo, o solo firmaste el contrato?
- ¿Tienes activadas las protecciones básicas en el navegador (CSP, cabeceras de seguridad)?
- ¿Te enterarías si los datos empezaran a fugarse ahora mismo?
Si la respuesta a alguna es no, el DPA no te salva.
Ataques de cadena de suministro: la amenaza real en 2026
Tus servidores pueden ser perfectos. Tu código propio puede estar revisado línea por línea. Y aún así te puede caer un ataque de cadena de suministro.
Funciona así. Cargas un script de una herramienta de analítica, un widget de chat, una librería de A/B testing. Ese script corre en los navegadores de tus usuarios con el mismo acceso que tu propio código. Si alguien compromete la fuente del script (la empresa que lo distribuye, su CDN, su pipeline de build), puede cambiar lo que se ejecuta en tu sitio sin tocar tus servidores.
El ejemplo clásico es Magecart. Los atacantes sustituyeron un script del formulario de pago por una versión que copiaba los números de tarjeta a un servidor suyo. British Airways, Ticketmaster, Newegg. Mismo patrón, distintas víctimas.
¿Qué puede hacer un script de terceros hackeado?
- Leer las pulsaciones en tus formularios
- Robar cookies de sesión y tokens
- Enviar cualquier contenido del DOM a un servidor del atacante
- Inyectar iframes ocultos para más ataques
Si esto ocurre, la pregunta de la AEPD será: ¿qué hizo usted para evitar que ese script de terceros leyera los datos de sus usuarios? “Confiábamos en el proveedor” no es una respuesta que ayude.
Dos defensas prácticas: SRI y CSP
No necesitas un equipo de seguridad para aplicarlas. Necesitas una tarde.
Subresource Integrity (SRI)
SRI es una verificación de hash que hace el navegador por ti. Cuando cargas un script externo, le das al navegador el hash esperado del archivo. Si el archivo cambia aunque sea un byte, el navegador se niega a ejecutarlo.
<script
src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>El truco: el proveedor tiene que darte un archivo estable. Muchos scripts de CDN cambian con frecuencia, lo que rompe SRI a propósito. Para esos, te alojas tú una versión conocida, generas el hash y actualizas según tu calendario.
Content Security Policy (CSP)
CSP es una cabecera que le dice al navegador desde dónde se permiten cargar scripts y, más importante, a dónde tienen permiso de enviar datos. Aunque un script esté comprometido y trate de exfiltrar a atacante.com, una CSP estricta bloquea la petición.
Un punto de partida tiene esta pinta:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.proveedor-confiable.com;
connect-src 'self' https://api.proveedor-confiable.com;
frame-ancestors 'none';Empieza en modo solo informe (Content-Security-Policy-Report-Only), observa una semana qué se rompe, y luego pasa a aplicar. Saltar directo al modo aplicado en un sitio en producción suele romper algo visible.
Qué castigan realmente las multas recientes
Existe una multa real de 3,2 millones de euros a una cadena de retail en 2025 que se cita mucho. Leyendo la resolución, la multa no fue por “tener una brecha”. Fue por el patrón alrededor de la brecha:
- Los atacantes estuvieron dentro semanas antes de que nadie lo notara
- Los paneles de administración no tenían MFA, solo contraseña
- Vulnerabilidades conocidas sin parchear durante meses
- Sin revisión de logs, sin alertas sobre tráfico anómalo
La lección no es “las multas dan miedo”. La lección es que una auditoría mira el proceso, no solo el resultado. Una empresa que detecta un incidente en dos horas y lo contiene recibe un trato muy distinto a una que se entera por un periodista tres meses después.
Una lista corta de hábitos que sí mueven la aguja
Olvida la metodología de cuatro pasos un momento. Si haces esto, ya estás por delante de la mayoría:
- Inventaria tus scripts de terceros. Saber qué corre en tus páginas y por qué. Quita lo que no uses.
- Fija versiones y usa SRI para todo lo que puedas autoalojar o cuyo proveedor publique archivos estables.
- Pon una CSP en marcha, aunque sea básica. Empieza en modo solo informe.
- Activa MFA en cada panel de administración, cuenta de hosting, proveedor de DNS y sistema de CI/CD.
- Lee tus logs de acceso al menos una vez por semana, o configura alertas básicas (Cloudflare y la mayoría de CDNs traen herramientas gratis para esto).
- Parchea según un calendario, no “cuando lleguemos”. Actualizaciones de seguridad en una semana, el resto cada mes.
Puedes leer guías prácticas relacionadas en este sitio: Mejores Prácticas para Banners de Cookies y Global Privacy Control (GPC).
Preguntas frecuentes
¿Basta con HTTPS para cumplir el Artículo 32? No. HTTPS cifra la conexión entre navegador y servidor. No hace nada respecto a lo que ocurre dentro del navegador, donde viven la mayoría de los ataques modernos. Sigues necesitando CSP, SRI, MFA, monitoreo y una cabecera HSTS bien configurada para evitar el SSL stripping.
¿Son peligrosos los scripts de analítica externos? Pueden serlo. Cualquier cosa que cargues de un tercero se ejecuta con acceso completo a la página. El riesgo no es que el proveedor sea malicioso, es que el proveedor sea comprometido. CSP limita a dónde puede enviar datos su script, que es la defensa principal.
¿Por qué usar SRI si el proveedor parece fiable? SRI no es un comentario sobre el proveedor. Es una comprobación de que el archivo que recibiste es el que esperabas. Los compromisos ocurren a nivel de CDN, en el pipeline de build, a veces por las credenciales robadas de un solo desarrollador. SRI detecta el cambio sin que tengas que verlo tú.