Skip to main content

Ticketing widget

Content Security Policy (CSP)

When you set up a Content Security Policy (CSP) on your website where the Ticketing widget is hosted, you have to make sure to allow some rules in your CSP.

What is Content Security Policy (CSP)

A Content Security Policy (CSP) is a security feature used by web applications to help prevent various types of attacks, such as Cross-Site Scripting (XSS) and data injection attacks. It works by defining a set of rules that specify which sources of content (e.g., scripts, styles, images, fonts) are allowed to be loaded and executed in a web page.

Rules required

Note

These rules are specific for ticketing and payment-widget.

You keep your own self and other sources and add the values below. self refers to your own site, so it doesn’t cover any widget resources.

Always required

Directive

Values

Why

script-src

https://widget.enviso.io

The loader, config and component modules

style-src

'unsafe-inline'

The loader adds a </style> element, and components use inline </style> attributes

connect-src

https://api.enviso.io

Ticketing API (also handles payments, captcha checks and Xafax/Intersolve)

img-src

https://widget.enviso.io

https://assets.enviso.io

data:

Widget icons, offer images, inline SVGs and profile pictures

Extra requirements for Enviso Pay

Required when card payments are enabled (including Bancontact card)

Directive

Values

Why

frame-src

https:

For in-page 3DS2 flow. The card issuer's 3D Secure screen loads in an iframe from the bank's own domain, which differs per bank, so this can't be narrowed.

form-action

https:

The 3DS challenge posts a form into that iframe.

Redirect-based methods (iDEAL, Bancontact mobile, Klarna, EPS, Twint…) and Worldline/Network redirects don't need these.

Optional: Only when the feature is used

Feature

Directive: Values

Google Pay

script-src, frame-src: https://pay.google.com (with a card saved in the Google account it may also trigger 3DS. See Required when card payments are enabled)

Apple Pay

script-src: https://applepay.cdn-apple.com

PayPal

script-src, frame-src, connect-src: https://*.paypal.com · img-src: https://*.paypalobjects.com

Customer login

connect-src, frame-src: https://login.enviso.io

Captcha

script-src, frame-src: https://challenges.cloudflare.com

Queue-it

script-src: https://static.queue-it.net · connect-src: https://*.queue-it.net

Visitor profile pictures

script-src, style-src: cdnjs.cloudflare.com

Datadog RUM

connect-src: https://browser-intake-datadoghq.eu

GTM / Google Analytics

Customers follow Google's own CSP guide for GTM / Google Analytics

Full example (cards, no optional features)

script-src   'self' https://widget.enviso.io
             https://checkoutshopper-live.adyen.com https://checkoutshopper-live.cdn.adyen.com;
style-src    'self' 'unsafe-inline'
             https://checkoutshopper-live.adyen.com https://checkoutshopper-live.cdn.adyen.com;
connect-src  'self' https://api.enviso.io
             https://checkoutshopper-live.adyen.com https://checkoutanalytics-live.adyen.com;
frame-src    https:;
img-src      'self' data: https://widget.enviso.io https://assets.enviso.io
             https://checkoutshopper-live.adyen.com https://checkoutshopper-live.cdn.adyen.com;
form-action  'self' https:;

frame-src https: already covers checkoutshopper-live.adyen.com, so the example doesn't list it separately.

Remarks

  • Nonce-based CSPs need 'strict-dynamic' added to script-src, because the loader creates its script tags at runtime.

  • Login popup: the popup returns to the customer's own page (same origin), so it needs no extra entries.

  • Not needed: 'unsafe-eval', worker-src and font-src.