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',
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 | |
connect-src | Allows XHR, fetch, and WebSocket connections to Noibu servers | |
worker-src | Allows Noibu's recording web workers to be created |
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) # Add to connect-src 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 |