CSP blocking admaxxer script.js

Admaxxer is a DTC analytics platform with built-in Meta + Google ad ops. A strict Content Security Policy will block the Admaxxer pixel if you have not allowlisted the script host and the beacon endpoint, which silently kills every event. TL;DR: add the Admaxxer domain to your script-src, connect-src, and img-src directives; reload the page and confirm the browser console has no CSP violations.

Symptoms

• The Admaxxer realtime pane shows no visitors even though the site has traffic.
• Browser DevTools -> Console prints errors like Refused to load the script 'https://admaxxer.com/script.js' because it violates the following Content Security Policy directive: "script-src 'self'".
• DevTools -> Network shows admaxxer/script.js as blocked (red) or 0 bytes.
• The pixel initializer window.admaxxer is undefined on window.
• Ecommerce events like purchase never appear in Admaxxer, but server webhook revenue still arrives.

Root cause

Modern sites ship a CSP header (either from the server or a <meta http-equiv> tag) that restricts where scripts, XHR/fetch, images, and beacons can go. The Admaxxer pixel has three networked paths:

1. The <script src="...admaxxer.com/script.js"> tag itself.
2. fetch / sendBeacon calls back to the Admaxxer ingest endpoint.
3. A 1x1 fallback pixel image for very old browsers or navigations where sendBeacon is not available.

If any of those paths is not in the CSP allowlist, the browser blocks it. The most common mistake is allowlisting script-src but forgetting connect-src, which silently swallows every fetch without a visible script error.

Fix

Step 1: Find your current CSP

Open DevTools -> Network -> click the root document -> Response Headers. Look for Content-Security-Policy. Copy it somewhere you can edit.

Step 2: Add Admaxxer to the script, connect, and img directives

A minimal diff looks roughly like this (replace admaxxer.com with your actual ingest domain if you are self-hosting):

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://admaxxer.com;
  connect-src 'self' https://admaxxer.com;
  img-src 'self' https://admaxxer.com data:;

If you use a <meta> tag CSP, edit the tag in your HTML template. If you use a header, edit it at your server or CDN.

Step 3: Handle nonces and hashes

If your CSP uses 'strict-dynamic' with nonces, add the nonce attribute to the Admaxxer script tag. If you hash inline scripts, the loader still has to be loaded from an allowlisted domain; the hash approach does not help here.

Step 4: Deploy and hard-reload

CSP is evaluated at load time. Clear the service worker cache and hard-refresh (Cmd+Shift+R) to confirm the new CSP is in effect — a stale HTML cache will keep the old CSP even after deploy.

Step 5: Repeat for staging and preview environments

A common regression is fixing production but leaving staging with the old CSP, which then leaks bad data back into testing.

Verify the fix

• DevTools -> Console has no Refused to load or Refused to connect errors mentioning Admaxxer.
• DevTools -> Network shows script.js returning 200 and POST / beacon requests to Admaxxer's ingest returning 2xx.
• window.admaxxer is defined in the console.
• Within about 30 seconds of a page load, the visitor appears in Admaxxer's realtime view.

Prevent it next time

• Treat CSP as code. Keep the CSP in version control so review catches allowlist drift.
• Use CSP reporting. Add report-to or report-uri so you see violations in aggregate even if nobody files a bug.
• Write an integration test. A headless-browser smoke test that checks window.admaxxer is present catches CSP regressions on every deploy.
• Document the allowlist in your install notes. If you onboard a new dev, they should find the required directives without digging.

Related guides

• Install Admaxxer with Google Tag Manager
• Next.js install + SPA pageview validation
• Verify revenue attribution after install

FAQs

Q: Can I use 'unsafe-inline' to make this go away? A: Technically yes, but that defeats most of CSP. Allowlisting the Admaxxer domain is safer.

Q: Why do I also need img-src? A: The pixel falls back to a 1x1 beacon image on page unload in some browsers where sendBeacon is flaky. Without img-src, those unload events are lost.

Q: Does the fix apply if my CSP is in a meta tag? A: Yes, but HTTP headers take precedence when both are present. If a header CSP still blocks, editing the meta tag alone will not help.