Dúas capas de seguridade que deben estar de acordo

Unha Content Security Policy (CSP) di ao navegador desde que fontes pode unha páxina cargar scripts, estilos, imaxes, frames e solicitudes de rede. Unha plataforma de xestión do consentimento fai o traballo contrario: decide cales deses scripts poden executarse segundo a elección do usuario. Cando se configuran por separado, chocan. O CMP non se carga porque a CSP o bloquea, ou a CSP aflóxase tanto para acomodar o CMP e as etiquetas de anuncios que xa non protexe nada.

Esta guía explica que directivas de CSP adoita precisar un CMP, como interactúan os nonces coa inxección de scripts e como despregar cambios sen romper o banner.

Que adoita precisar un CMP da CSP

Os requisitos exactos dependen do provedor, así que parte sempre da documentación do teu CMP. En xeral, comproba estas directivas:

• script-src — o dominio desde o que se carga o script do CMP, máis calquera outro ficheiro de script que cargue.
• connect-src — os puntos finais que o CMP chama con fetch ou XHR, como os de configuración, lista de provedores, xeolocalización e rexistro do consentimento.
• style-src — o dominio da folla de estilos, e posiblemente os estilos en liña se o CMP inxecta un elemento <style> ou define atributos de estilo.
• img-src — logotipos, iconas e calquera píxel sen seguimento que use o CMP.
• font-src — se o banner carga as súas propias tipografías.
• frame-src — se o CMP usa iframes, por exemplo para compartir o consentimento entre dominios.

En sitios con TCF, lembra que o CMP tamén crea un frame localizador chamado __tcfapiLocator na páxina. Ese frame créase sen fonte remota, polo que normalmente non precisa unha entrada en frame-src, pero convén confirmalo nas probas.

O problema do stub en liña

A maioría dos CMP piden que poñas un pequeno script en liña — o stub — no head da páxina, para que outros scripts poidan poñer chamadas en cola antes de que se cargue o CMP principal. Unha CSP estrita bloquea os scripts en liña salvo que os permitas explicitamente. Tes tres opcións:

1. Un nonce. Xera un valor aleatorio por resposta, engádeo á cabeceira CSP como 'nonce-...' e á etiqueta <script> do stub. É a opción máis flexible para páxinas dinámicas.
2. Un hash. Engade o hash SHA-256 do contido exacto do stub a script-src. Funciona ben para sitios estáticos, pero calquera cambio no stub, mesmo de espazos en branco, rómpeo.
3. Aloxar o stub por conta propia como ficheiro externo no teu propio dominio, cuberto por 'self'. Hai que ter coidado para que se cargue o bastante cedo.

Evita 'unsafe-inline' como atallo. Permite todos os scripts en liña, o que elimina gran parte da protección que ofrece a CSP.

Nonces e scripts que inxecta o CMP

Un CMP que bloquea scripts ata o consentimento adoita funcionar retendo e inxectándoos máis tarde. Cunha CSP baseada en nonces, eses scripts inxectados tamén se deben permitir. Hai dous enfoques habituais:

• Propagación do nonce. O CMP le o nonce da súa propia etiqueta de script e engádeo a cada script que inxecta. Comproba se o teu CMP o admite.
• 'strict-dynamic'. Esta palabra clave indica aos navegadores compatibles que confíen nos scripts cargados por un script xa de confianza. Simplifica a vida con xestores de etiquetas e CMP que inxectan scripts, pero tamén significa que calquera script no que confíes pode cargar outros, así que confía con coidado.

Os xestores de etiquetas plantexan a mesma cuestión. Se cargas etiquetas de anuncios e de analítica mediante un xestor de etiquetas, segue a súa documentación sobre nonces e asegúrate de que o CMP e o xestor de etiquetas usen un enfoque coherente.

As etiquetas de anuncios complican a CSP

A publicidade programática carga scripts e frames de moitos dominios, e a lista cambia a medida que cambian os socios de demanda. Os publishers adoitan facer unha destas dúas eleccións:

• Unha CSP estrita nas páxinas sen anuncios programáticos, e unha política máis ampla onde se executan anuncios.
• Unha política centrada en directivas que seguen sendo manexables, como frame-ancestors, object-src 'none' e base-uri, mentres que as fontes de scripts se manteñen máis amplas.

En calquera caso, o CMP debería estar na lista de permitidos explícita, non cuberto só por un comodín, para que un cambio de CSP nunca desactive o banner en silencio.

Despliega co modo só informe

Usa primeiro a cabeceira Content-Security-Policy-Report-Only. O navegador informa das violacións sen bloquear nada, así que podes ver que rompería unha política nova.

1. Despliega a política en modo só informe cun punto final de informes.
2. Carga páxinas en perfís de navegador limpos e percorre todo o fluxo de consentimento: primeira visita, aceptar todo, rexeitar todo, elección personalizada, retirada.
3. Revisa os informes de violacións e a consola do navegador para detectar recursos do CMP bloqueados.
4. Axusta a política e despois pasa á aplicación efectiva.
5. Mantén os informes activados despois da aplicación para detectar regresións.

Síntomas dun conflito de CSP

• O banner nunca aparece, e a consola amosa unha violación de CSP para o script do CMP.
• O banner aparece pero sen estilos, porque style-src bloquea o seu CSS.
• As eleccións non se gardan, porque connect-src bloquea a chamada de rexistro do consentimento.
• Os anuncios ou a analítica nunca se cargan despois do consentimento, porque aos scripts inxectados lles falta un nonce.
• __tcfapi non está definido, porque o stub en liña foi bloqueado.

Ideas clave

• Comproba script-src, connect-src, style-src, img-src e frame-src para o teu CMP.
• Permite o stub en liña cun nonce ou un hash, non con 'unsafe-inline'.
• Asegúrate de que os scripts inxectados despois do consentimento reciban un nonce ou queden cubertos por 'strict-dynamic'.
• Proba cada camiño de consentimento en modo só informe antes de aplicar a política.
• Mantén o CMP na lista de permitidos de maneira explícita para que os cambios de CSP non o poidan desactivar.