Whitelisting Troubleshooting Guide

Last updated: June 26, 2026

Overview

When Noibu is not capturing sessions, the root cause is almost always one of the following two issues:

Script not deployed - The Noibu script tag is missing from the page HTML entirely.
CSP misconfiguration - The site's Content Security Policy allows the script to load but blocks the outbound connections and workers Noibu needs to transmit data.

Prerequisites

Before running the steps below, confirm the following:

You have access to Chrome (or any Chromium-based browser).
You can open Chrome DevTools on the website (F12 or Cmd+Option+I).
You know the domain URL.

1. Confirm the Noibu script is deployed

Open Chrome DevTools on the website, go to the Console tab, and run:

Array.from(document.querySelectorAll('script'))

.map(s => s.src)

.filter(s => s.includes('noibu'))

Interpreting the result

Array with noibu URLs	Script is deployed. Proceed to Step 2.	✓ PASS
Empty array []	Script is not deployed. Follow the platform deployment guide and re-test.	✗ FAIL

Expected output when deployed

[ 'https://cdn.noibu.com/collect-core.js',

'https://cdn.noibu.com/collect-recording.js',

'https://cdn.noibu.com/collect-webvitals.js' ]

2. Confirm Noibu initialises correctly

Even if the script tags are present, the scripts may not be executing. Run the following in the Console:

({

windowNoibu: typeof window.NOIBUJS

})

Interpreting the result

Value is NOT 'undefined'	Noibu has initialised. Check the Noibu console for session data.	✓ PASS
Value is 'undefined'	Scripts are present but not executing. Proceed to Step 3 (consent) and Step 4 (CSP).	✗ FAIL

3. Check the Content Security Policy (CSP)

A CSP controls which external domains a page can load scripts from, make network requests to, and create workers from. Even if Noibu's scripts load successfully, the CSP may block the outbound connections Noibu needs to transmit session data.

3a — Retrieve and parse the CSP header

Run the following in the Console to extract the relevant CSP directives:

const resp = await fetch(window.location.href, { method: 'HEAD' });

const csp = resp.headers.get('content-security-policy');

if (!csp) {

console.log('No CSP header found. Noibu should not be blocked by CSP.');

} else {

const directives = csp.split(';').map(d => d.trim());

const relevant = directives.filter(d =>

d.startsWith('script-src') ||

d.startsWith('connect-src') ||

d.startsWith('worker-src') ||

d.startsWith('default-src')

);

console.log(relevant.join('\n\n'));

console.log('script-src has noibu:', relevant.some(d => d.startsWith('script-src') && d.includes('noibu')));

console.log('connect-src has noibu:', relevant.some(d => d.startsWith('connect-src') && d.includes('noibu')));

console.log('worker-src has noibu:', relevant.some(d => d.startsWith('worker-src') && d.includes('noibu')));

}

What to look for:

script-src	Allows Noibu script files to load	*.noibu.com
connect-src	Allows XHR, fetch, and WebSocket connections to Noibu servers	.noibu.com wss://.noibu.com
worker-src	Allows Noibu's recording web workers to be created	*.noibu.com

3b — Actively test each capability

Run the following in the Console to confirm whether the CSP is actively blocking Noibu's runtime connections. This test works even if the CSP header was not found in Step 4a (some CSPs are delivered via meta tags or middleware):

(async () => {

const results = {};

// Test 1: Can the page fetch from *.noibu.com? (connect-src)

try {

await fetch('https://cdn.noibu.com/', { mode: 'no-cors' });

results.fetch = 'ALLOWED';

} catch(e) {

results.fetch = 'BLOCKED: ' + e.message;

}

// Test 2: Can it open a WebSocket to wss://*.noibu.com? (connect-src)

const ws = new WebSocket('wss://ws.noibu.com');

await new Promise(resolve => {

ws.onerror = () => { results.websocket = 'BLOCKED'; resolve(); };

ws.onopen = () => { results.websocket = 'ALLOWED'; ws.close(); resolve(); };

setTimeout(resolve, 3000);

});

// Test 3: Can it create a Worker from *.noibu.com? (worker-src)

try {

new Worker('https://cdn.noibu.com/collect-recording.js');

results.worker = 'ALLOWED';

} catch(e) {

results.worker = 'BLOCKED: ' + e.message;

}

console.table(results);

})()

Interpreting the result

fetch	ALLOWED	✓ PASS
fetch	BLOCKED: Failed to fetch	✗ FAIL
websocket	ALLOWED	✓ PASS
websocket	BLOCKED (error event)	✗ FAIL
worker	ALLOWED	✓ PASS
worker	BLOCKED: Script at '...' cannot be accessed from origin '...'	✗ FAIL

Note on the Worker error message

The message 'Script at ... cannot be accessed from origin ...' is the browser's CSP violation message, not a CORS error.

A CORS error would say 'No Access-Control-Allow-Origin header'. If you see the 'cannot be accessed' wording, the CSP worker-src directive is the cause.

3c — Fix

Get your development team to update the site's CSP configuration to add the following to each directive:

# Add to script-src (if not already present)

*.noibu.com

# Add to connect-src

*.noibu.com

wss://*.noibu.com

# Add worker-src directive (create it if it does not exist)

worker-src *.noibu.com

On Magento 2 sites, the CSP is configured in the Magento Admin or in a module's csp_whitelist.xml file. On other platforms, refer to the platform's documentation for CSP configuration.

Additional Whitelisting Requirements

Beyond the CSP, Noibu's servers also need to be able to access the CDN in order to replay sessions and beautify stack traces. If session replays appear blank or stack traces are unreadable, the following also need to be whitelisted on the CDN or WAF:

URLs	https://.noibu.com wss://.noibu.com
IP Addresses	34.123.113.243 34.69.76.245
User-Agent	Noibu JS Beautifier