Show Menu
TEMAS×

Política de seguridad de contenido (CSP)

El objetivo principal de una Política de seguridad de contenido (CSP) es evitar ataques de scripts entre sitios (XSS). Esto sucede cuando se engaña al explorador para que ejecute contenido malicioso que parece provenir de una fuente de confianza, pero que realmente proviene de otro lugar. CSP permite al navegador (en nombre del usuario) verificar que el script viene de una fuente de confianza.
La CSP se implementa añadiendo el encabezado HTTP de Content-Security-Policy a las respuestas del servidor. Puede leer más sobre la CSP en el sitio Mozilla Developer Network: https://developer.mozilla.org/es-ES/docs/Web/HTTP/CSP

Problemas que superar

Los sistemas de administración de etiquetas están diseñados para cargar scripts dinámicamente. El CSP está diseñado para bloquear estos scripts cargados dinámicamente porque pueden provocar problemas de seguridad.
Si quiere que Launch funcione con su CSP, existen dos desafíos principales que se deben superar:
  • El origen de la biblioteca de Launch debe ser de confianza. Si no se cumple esta condición, el explorador bloqueará la biblioteca de Launch y otros archivos JavaScript necesarios y no se cargarán en la página.
  • Se deben permitir los scripts en línea. Si no se cumple esta condición, las acciones de regla de código personalizado se bloquean en la página y no se ejecutan correctamente.
Si desea utilizar Launch y dispone de un CSP, debe corregir ambos problemas sin marcar incorrectamente otros scripts como seguros. El aumento de la seguridad significa aumentar también la cantidad de trabajo por su parte.

Fuentes de confianza

Si está alojando su biblioteca usted mismo, la fuente de su biblioteca es probablemente su propio dominio. Puede especificar que el dominio host sea un origen seguro como este:
script-src 'self'
Si Adobe aloja la biblioteca (con el host Administrado por Adobe), la biblioteca se mantiene en assets.adobedtm.com. En este caso, la directiva debe tener este aspecto:
script-src 'self' assets.adobedtm.com
Debe especificar self como dominio seguro para que no se rompan los scripts que ya se están cargando, pero también necesita que assets.adobedtm.com aparezca como seguro o la biblioteca de Launch no se cargará en la página.
Puede leer más sobre las fuentes de confianza en el sitio Mozilla Developer Network:

Scripts en línea

Los scripts en línea presentan un desafío para el CSP porque no están permitidos de forma predeterminada. Tiene dos opciones para permitir scripts en línea:
  • Permitir todos los scripts en línea (menos seguro)
  • Permitir a través de nonce (buena seguridad)
La especificación del CSP tiene detalles para una tercera opción usando almohadillas, pero este enfoque no se puede usar con un TMS de cualquier tipo por diferentes motivos, algunos muy complicados.

Seguridad adecuada - Nonces

Este método implica generar un nonce y agregarlo al CSP y a cada script en línea. Cuando el explorador recibe una instrucción para cargar un script en línea con una cadena nonce, compare el valor nonce con el contenido en el encabezado CSP. Si coincide, se carga la secuencia de comandos.
Esta cadena nonce debe cambiarse con cada nueva carga de página.
Hay un requisito previo muy importante: Debe cargar la biblioteca de Launch asincrónicamente . Esto no funciona con una carga sincrónica de la biblioteca de Launch (lo que provoca errores de consola y reglas que no se ejecutan correctamente).
Puede añadir el nonce al CSP alojado en Adobe de esta manera:
script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'
Luego debe indicar a Launch dónde buscar el nonce. Launch lo utiliza al cargar un script en línea. Para que Launch use el nonce cuando carga el script, debe:
  1. Crear un elemento de datos que haga referencia a su nonce (ubicación que haya elegido en la capa de datos).
  2. Configurar la extensión principal y especificar qué elemento de datos ha utilizado.
  3. Publicar los cambios de su elemento de datos y extensión principal.
Nota adicional: Esto solo controla la carga del código personalizado. No gestiona lo que hace en su código personalizado. Puede escribir código personalizado que no cumpla con su CSP, en cuyo caso el CSP tiene preferencia. Por ejemplo, si utiliza un código personalizado para cartar scripts en línea anexándolos al DOM, Launch no podrá encontrarlo ni añadir el nonce correctamente, así que la acción de ese código personalizado en particular no funcionará como se esperaba.

Seguridad baja: Permitir en línea

Si la opción anterior no le funciona, puede indicarle a su CSP que permita los scripts en línea. Esta es la opción menos segura, pero también más fácil de implementar y mantener.
De nuevo, suponiendo que Adobe administre el alojamiento y marque el dominio assets.adobedtm.com como fuente de confianza, el CSP tendría este aspecto:
script-src 'self' assets.adobedtm.com 'unsafe-inline'
Para saber más sobre cómo permitir los scripts en línea, consulte https://developer.mozilla.org/es-ES/docs/Web/HTTP/Headers/Content-Security-Policy/script-src en el sitio de MDN.