Fix Content Security Policy errors that block the Admaxxer pixel

What the pixel needs your policy to allow

The pixel is a single external script. It loads from one origin and sends all of its requests (events, batched events and identify calls) back to that same origin. It doesn't load other scripts, images, frames or fonts, so only two directives matter: script-src for the script and connect-src for the requests.

'self' covers only your page's own host

On www.yourbrand.com, 'self' does not cover t.yourbrand.com or any other subdomain. If the pixel loads from a different subdomain, whether a tracking domain or a proxy on another host, list that subdomain explicitly.

Step 1: Confirm the policy is the cause

1. Open your site and your browser's developer tools, then reload the page.
2. In the Console, look for an error that mentions Content Security Policy and names the pixel's script or event address.
3. In the Network tab, filter for script or event. Chrome lists a request your policy blocked with the status (blocked:csp).

Typical console messages (exact wording varies by browser)

Refused to load the script 'https://admaxxer.com/js/script.js' because it violates the following Content Security Policy directive: "script-src 'self'".

Refused to connect to 'https://admaxxer.com/api/event' because it violates the following Content Security Policy directive: "connect-src 'self'".

If Chrome shows the request failing with net::ERR_BLOCKED_BY_CLIENT instead, that's a browser extension such as an ad blocker, not your policy. A first-party tracking domain helps with that.

Step 2: Find where your policy is set

• A response header called Content-Security-Policy, set by your web server, CDN or framework middleware.
• A meta tag in your page's HTML: meta http-equiv="Content-Security-Policy".
• A framework or plugin setting, for example a headers() entry in a Next.js config, a Rails initializer, or a security plugin on WordPress.

To see the header, run curl -sI https://yourdomain.com | grep -i content-security-policy. A meta-tag policy won't show up there, so also check your page source.

Step 3: Add the pixel's origin

Add the origin to your existing policy. Don't replace your policy with a two-line one: anything you leave out, including your own scripts, would then be blocked.

Before

Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'

After (standard install)

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

• No script-src or connect-src in your policy? The browser falls back to default-src for both. Either add the origin to default-src, or add the two directives, and include everything default-src already allowed, because a specific directive replaces default-src for that type.
• Using 'strict-dynamic'? Browsers that support it ignore host allowlists for scripts, so add your policy's nonce attribute to the Admaxxer script tag instead.
• In the app: the Install tab of your site settings has a Content Security Policy (CSP) card with the directives ready to copy. Merge them into your policy rather than pasting the card's complete line on its own.

Next.js

next.config.js

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "default-src 'self'; script-src 'self' https://admaxxer.com; connect-src 'self' https://admaxxer.com",
          },
        ],
      },
    ];
  },
};

NGINX

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://admaxxer.com; connect-src 'self' https://admaxxer.com" always;

Apache

.htaccess

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://admaxxer.com; connect-src 'self' https://admaxxer.com"

Rails

config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy do |policy|
  policy.script_src  :self, 'https://admaxxer.com'
  policy.connect_src :self, 'https://admaxxer.com'
end

These examples show a minimal policy so the change is easy to see. Keep every other source and directive your site already uses. With a first-party tracking domain, use your tracking subdomain in place of https://admaxxer.com.

Step 4: Confirm the fix

1. Reload your site. The Content Security Policy errors should be gone from the Console.
2. In the Network tab, the pixel script and the event requests should complete instead of showing (blocked:csp).
3. Open Dashboard → Pixel. The Live Visitors card counts pageviews from the last five minutes and refreshes every 10 seconds.

Still blocked?

• More than one policy. If a header and a meta tag both set a policy, or two layers each add a header, the browser enforces all of them. Every one has to allow the pixel.
• Your CDN or hosting adds its own header. Check the response the browser actually receives, not just your app's config.
• Report-only messages. A Content-Security-Policy-Report-Only header only reports; it doesn't block. If you only see report-only messages, the blocking policy is somewhere else, or the problem isn't the policy.
• Not a policy problem. If there's no Content Security Policy error at all, see Install the pixel to recheck your setup.

Frequently asked questions

Related guides

• First-party tracking domain — Serve the pixel from your own subdomain.
• Proxy the pixel through NGINX — Run the pixel through your own server.
• Proxy the pixel through Cloudflare — Forward pixel traffic with a Cloudflare Worker.
• Script configuration — Every attribute the pixel script reads.
• Install the pixel — Install guides for every platform.