Content Security Policy y headers

Si tu checkout usa Content Security Policy (CSP), debe permitir el snippet de Proteside. El dashboard no genera una CSP por ti: esta página lista lo que el SDK usa realmente en el navegador, para que lo incluyas en la política de la tienda.

Directivas necesariasCopiar enlace de la sección

Sin connect-src para app.proteside.com, el SDK carga y se ejecuta, pero ningún evento llega al dashboard. Sin el permiso opcional para los orígenes de los scripts, el SDK no calcula el hash de esos scripts: quedan en el inventario como monitoreados, sin hash, y el navegador genera reportes de violación para esos hosts.

Los scripts inline del snippetCopiar enlace de la sección

El bootstrapper es inline y debe seguir siéndolo (consulta Instalación del snippet). Elige una forma de autorizarlo:

• Hash ('sha256-…'): autoriza exactamente ese contenido. El hash cambia cuando cambia el contenido del script: cada vez que vuelves a pegar un snippet de una versión nueva y, si la tienda tiene reglas inline, siempre que vuelves a pegar el snippet después de cambiar reglas o contenedores de Google Tag Manager, porque la configuración window.__PROTE_INLINE__ va al principio del mismo script. Los snippets antiguos, con esa configuración en una etiqueta separada, necesitan un segundo hash para ella.
• Nonce: si tu servidor ya genera un nonce por respuesta, agrega el atributo nonce a las etiquetas <script> del snippet al pegarlo en la plantilla. El snippet del dashboard no trae nonce.
• 'unsafe-inline': funciona, pero habilita cualquier script inline y debilita la política. No se recomienda en páginas de pago.

La forma más segura de obtener el hash es dejar que el navegador lo calcule: publica la CSP sin el hash (de preferencia en modo Content-Security-Policy-Report-Only), abre el checkout y mira el mensaje de violación en la consola. Indica el valor 'sha256-…' del script bloqueado. Para calcularlo localmente, usa exactamente el contenido entre <script> y </script>, sin salto de línea al final:

# bootstrapper.js = contenido entre <script> y </script>, copiado del snippet
printf '%s' "$(cat bootstrapper.js)" | openssl dgst -sha256 -binary | openssl base64

Ejemplo de headerCopiar enlace de la sección

Un ejemplo para un checkout en mitienda.com con Stripe. Adapta los demás orígenes a tu tienda.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'sha256-BOOTSTRAPPER_HASH' https://cdn.proteside.com https://js.stripe.com;
  connect-src 'self' https://app.proteside.com https://api.stripe.com;
  frame-src https://js.stripe.com;
  img-src 'self' data:;
  style-src 'self';
  report-uri https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e;
  report-to proteside
Reporting-Endpoints: proteside="https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e"

El header real va en una sola línea; los saltos de arriba son solo para facilitar la lectura. Si tu snippet usa el formato antiguo, con window.__PROTE_INLINE__ en una etiqueta <script> separada, agrega también el hash de esa etiqueta.

Reportes de violaciónCopiar enlace de la sección

Proteside recibe reportes de CSP en la dirección de abajo. No aparece en ninguna pantalla del dashboard; usa tu clave del SDK en el parámetro key:

https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e

• Acepta los dos formatos: report-uri y report-to (Reporting API).
• El total aparece en Salud del SDK, en la tarjeta Reportes CSP (48 h).
• Una violación de script-src o connect-src hacia un host que no está en el inventario de scripts de la tienda se convierte en la alerta CSP_VIOLATION, con severidad baja. Las violaciones de otras directivas solo entran en el conteo.
• Por encima de 600 reportes por minuto por clave, el excedente se descarta.

Para probar una política nueva sin romper el checkout, publícala primero como Content-Security-Policy-Report-Only, sigue los reportes y después cámbiala a Content-Security-Policy.

Headers de seguridad monitoreadosCopiar enlace de la sección

Para respaldar la detección de cambios en los headers, el SDK lee los headers de seguridad de la página de pago en cada carga y en cada Proteside.pageChanged():

Content-Security-Policy, Content-Security-Policy-Report-Only, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy, Access-Control-Allow-Origin y Set-Cookie (este solo como "no legible en el navegador").

El valor de cada header presente se envía al dashboard. Cuando un valor cambia, el dashboard crea la alerta HEADER_CHANGED. Los headers aparecen en Evidencias PCI DSS, en la pestaña Cabeceras.

Subresource Integrity (SRI)Copiar enlace de la sección

No uses el atributo integrity en la etiqueta del shield.js. Hoy el SRI no es viable por dos motivos:

1. La URL es mutable. La misma dirección recibe cada nueva versión del SDK, así que el hash cambiaría con cada publicación y el navegador empezaría a rechazar el script.
2. La CDN no envía headers de CORS. Un <script integrity crossorigin="anonymous"> exige CORS, y el navegador bloquearía la carga.

Como control preventivo, restringe script-src a https://cdn.proteside.com y autoriza el bootstrapper inline por hash o nonce. El inventario de Proteside registra qué scripts de tu página usan integrity y nonce.

Relación con PCI DSS 4.0Copiar enlace de la sección

Proteside genera evidencias para estos requisitos en Evidencias PCI DSS. La evaluación de cumplimiento sigue siendo responsabilidad de tu evaluador (QSA) o de tu cuestionario de autoevaluación. Consulta Evidencias PCI DSS.

Próximos pasosCopiar enlace de la sección

• Privacidad y LGPD
• Solución de problemas