Andes Consent: consentimiento de cookies y evidencia con seguridad de nivel bancario

Andes Consent es el sistema de consentimiento de cookies que construimos para instituciones donde la seguridad no se negocia. Tiene dos piezas: un script de 16 KB, sin dependencias, que corre bajo políticas de seguridad de contenido (CSP) estrictas y Trusted Types, y un gestor de recibos donde cada decisión del visitante queda guardada como evidencia que nadie puede editar. Hoy está en producción en una institución financiera regional.

// El desafío

Pedir consentimiento parece sencillo hasta que la plataforma tiene estándares de seguridad bancarios y alguien tiene que demostrar, años después, qué aceptó cada visitante. Los retos clave fueron:

• El guardián que abre la puerta Las plataformas de consentimiento comerciales suelen exigir unsafe-inline o eval, justo lo que una CSP estricta prohíbe. El script que debía proteger la privacidad terminaba debilitando la seguridad del sitio.
• Bloqueo real, no cosmético Los scripts de medición y los iframes de terceros no pueden ejecutarse antes de que el visitante acepte, sin romper el orden de carga ni la integridad de los scripts.
• Una cookie no es evidencia Cuando un regulador pregunta qué aceptó una persona hace dos años y qué texto tenía enfrente, la cookie de su navegador ya no existe. Y un registro que el propio equipo puede editar no prueba nada.
• Un mapa regulatorio fragmentado Un sitio corporativo en la región responde a GDPR, CCPA, la ley de privacidad de Texas y las leyes de Brasil, México, Chile, Colombia y El Salvador. Las reglas de California, además, exigen respetar la señal Global Privacy Control de forma visible y no volver a preguntar a quien ya dijo que no.
• Accesible para todos El banner es lo primero que ve cada visitante; tiene que funcionar con teclado y lector de pantalla.

// La solución tecnológica

Andes Development construyó dos piezas que funcionan juntas o por separado.

El script es pequeño, auditable y pensado desde el primer día para convivir con una CSP estricta:

• TypeScript puro, cero dependencias Un solo archivo que funciona en cualquier sitio, con presupuestos de tamaño verificados en cada build: unos 16 KB de JavaScript y 3 KB de CSS comprimidos.
• Seguro bajo CSP estricta Probado con nonce + strict-dynamic y con Trusted Types. Sin eval, sin Function, sin inyección de HTML, con protección contra prototype pollution y una API pública congelada.
• Bloqueo previo declarativo Los scripts se marcan en el HTML y solo se activan con consentimiento, conservando su orden, su nonce y su hash de integridad (SRI). Los iframes de terceros se muestran como fachadas hasta que el visitante acepta.
• Confianza acotada Una lista de orígenes permitidos para los scripts controlados. La configuración remota se valida al cargar y nunca puede ampliar esa confianza.
• Señales para Google y para California Google Consent Mode v2 en modo básico o avanzado, eventos en dataLayer, modos opt-in y opt-out y borrado de cookies al retirar el consentimiento. Cuando el navegador envía Global Privacy Control, el panel de preferencias le muestra al visitante que su señal fue respetada, y una decisión de exclusión se conserva aunque cambie la política, sin volver a preguntar durante 12 meses.
• Marca y accesibilidad Banner en Shadow DOM con cinco diseños, temas por marca en modo claro y oscuro, español e inglés, y WCAG 2.2 AA verificado automáticamente en cada tema.
• Entrega verificable Cada versión se entrega como paquete con hashes SRI, para que el cliente lo aloje en su propia infraestructura.

El gestor de recibos recibe cada decisión y la guarda como evidencia:

• Recibos que solo se insertan La base de datos rechaza cualquier edición o borrado, venga de quien venga, incluido un administrador de la plataforma. Solo la depuración por retención puede eliminar recibos vencidos, y cada depuración queda registrada.
• Cada recibo atado al texto que se vio Cada revisión de la política se archiva con su configuración y sus textos en español e inglés. Cuando llega el primer recibo, esa revisión se bloquea; las correcciones posteriores solo se agregan como notas.
• La IP nunca se guarda Se almacena solo como un hash con una llave propia de cada cliente, que además se puede rotar.
• Ingesta acotada Un recibo se acepta solo con un token válido del sitio, un origen en la lista autorizada de ese sitio y un formato válido, con límites por visitante, por sitio y por IP, y un tope de 8 KB por solicitud.
• Consultas para cumplimiento El equipo de cumplimiento busca el historial de un visitante por su ID de consentimiento, y cada búsqueda queda auditada. Las exportaciones a CSV o Excel están protegidas contra inyección de fórmulas y solo las descarga quien las pidió, mediante un enlace firmado.
• Acceso controlado Paneles separados para el cliente y para el equipo de Andes, roles por cliente (cumplimiento, consulta y desarrollo), segundo factor y llaves de acceso obligatorios, y contraseñas que solo se definen desde un enlace enviado por correo. La retención se define por cliente, con cinco años por defecto.

El gestor es opcional: el script también puede enviar los recibos a un servidor de la propia institución. Y no implementa el marco IAB TCF, por decisión: está pensado para sitios corporativos y plataformas reguladas, no para redes de publicidad programática, y esa decisión es parte de lo que lo mantiene en 16 KB.

// Resultados y logros destacados

Un sistema de consentimiento que la seguridad del sitio no tiene que tolerar, porque puede auditarlo:

• 16 KB

  Script completo comprimido, sin dependencias y dentro de un presupuesto de tamaño que se valida en cada build.

• 361 pruebas

  195 pruebas unitarias y 166 de extremo a extremo en Chromium, Firefox y WebKit, más una auditoría de seguridad con todos sus hallazgos corregidos.

• 3 capas

  El modelo, un disparador en la base de datos y las llaves foráneas impiden que un recibo se edite o se borre fuera de su plazo de retención.

// Conclusión

Andes Consent resuelve dos problemas que vemos seguido en plataformas corporativas: pedir permiso sin debilitar la seguridad del sitio y demostrar después qué permiso se dio. Es pequeño, auditable y construido con el mismo rigor que aplicamos en banca. Hoy funciona en el sitio de una institución financiera regional, donde cada decisión de un visitante queda como un recibo que el equipo de cumplimiento puede presentar.