Skip to main content
If your site sends a Content-Security-Policy header, you need to allow the Cashback Hive host in two directives. If you don’t use a CSP, nothing here applies.

​
Required directives

The SDK doesn’t use eval, inline scripts, inline styles, iframes, web workers or WebSockets, so no 'unsafe-inline', 'unsafe-eval', frame-src or worker-src entries are needed.

​
Optional directives

​
Things CSP doesn’t govern

These are worth knowing about when reviewing the integration, even though no directive is required:
  • Sign-in popup. auth.signIn() opens https://sdk.cashbackhive.com/v1/auth in a new window with window.open. CSP doesn’t restrict popups. If popups are blocked, the SDK falls back to a full-page redirect, which navigate-to would govern in browsers that implement it (none do at the time of writing).
  • Tracked clicks. openOffer() opens https://shop.cashbackhive.com/click/… in a new tab. Same as above.
  • postMessage. The sign-in window sends the token back with postMessage. The SDK checks the message origin itself; CSP isn’t involved.
  • localStorage. The member token is stored under cbh:<key>:token. Not CSP-governed.

​
Example: Next.js

A minimal policy in next.config.ts:
Next.js itself needs 'unsafe-inline' or a nonce for script-src in development and for some runtime scripts. See the Next.js CSP guide for a nonce-based setup. Adding a nonce to the SDK <Script> tag works normally.

​
Testing a policy safely

Deploy with Content-Security-Policy-Report-Only first. Violations are reported to the console (and to a report-to endpoint if you set one) without blocking anything, so you can confirm the SDK works before enforcing.