The HubSpot tracking code is installed. You have checked the source, the snippet is there, and HubSpot's own verification tool may even pass. Yet page views are not arriving, form analytics look empty, and the campaign reports you promised are quietly failing. When everything looks right and nothing works, the culprit is often a security layer marketing never sees: the site's Content Security Policy.
Content Security Policy problems are common on corporate and regulated-industry websites, where IT deliberately restricts which external scripts may run. The fix is simple once diagnosed — but the diagnosis and the change process both have to go through the right people.
Quick Answer
A Content Security Policy (CSP) is a website security header that controls which domains may load scripts and resources; if HubSpot's domains are not allowlisted, the browser blocks the tracking code and no analytics or attribution data reaches HubSpot. Diagnose it by checking the browser developer console for CSP violation errors, then have your web or security team add HubSpot's tracking domains to the policy and retest. This matters for any organization with strict web security — especially financial services and other regulated industries — and Vantage Point handles tracking and security coordination in HubSpot engagements and compliance-sensitive projects.
Key Takeaways (TL;DR)
- What a CSP is: a browser-enforced allowlist of domains permitted to run scripts and load resources on your site.
- The symptom: tracking code present in the page source, but no page views, form analytics, or attribution in HubSpot.
- The diagnosis: CSP violation errors in the browser's developer console naming the blocked HubSpot domains.
- The fix: add HubSpot's script and beacon domains to the policy, then verify data flows — often after security or compliance sign-off.
- How Vantage Point helps: tracking implementation and cross-team coordination through HubSpot implementation services.
What Is a Content Security Policy?
A Content Security Policy is an HTTP response header — or a meta tag — that tells the browser exactly which sources are allowed to provide scripts, styles, images, frames, and connections for your pages. Its purpose is defense: if an attacker injects a malicious script tag, the browser refuses to execute it because the source is not on the list. MDN's CSP reference documents the directives and behaviors in detail.
Strict CSPs are standard practice at security-conscious organizations, and they are often required by internal policy or by regulators' expectations. The side effect is that any legitimate third-party tool — analytics, chat, A/B testing, CRM tracking — silently fails until its domains are explicitly added.
How Does a CSP Block HubSpot Tracking?
The HubSpot tracking code is a JavaScript file loaded from HubSpot's domains, which then communicates with HubSpot's analytics endpoints. Both legs must survive the policy. If the policy's script-src directive omits HubSpot's script host, the file never loads. If the script loads but the connect-src or img-src directives omit the collection endpoints, the tracking beacons die in transit. Either way, HubSpot receives nothing.
Google Tag Manager does not rescue you here. GTM is itself a third-party script subject to the same policy, so a CSP that blocks GTM also blocks everything GTM would have loaded, including HubSpot. Teams sometimes "fix" this by allowing GTM, only to find the HubSpot tags inside it still blocked by their own rules.
How Do You Diagnose a CSP Block?
- Confirm the code is installed. View the page source and check for the tracking snippet. HubSpot's tracking code installation guide shows what the snippet should look like, and the troubleshooting guide covers HubSpot's verification tool.
- Open the browser developer console. On the live page, open DevTools and look for red errors reading "Refused to load the script" or "violates the following Content Security Policy directive," naming the blocked domain.
- Check the network tab. Look for requests to HubSpot hosts with a blocked or failed status. Note every domain that appears — scripts, beacons, and forms may use different ones.
- Read the policy itself. In the network tab, inspect the page's response headers for the Content-Security-Policy header, or ask your web team where the policy is managed — a server config, a CDN rule, or a tag manager.
- Rule out the simple stuff first. Ad blockers and strict browser privacy modes also block HubSpot. Reproduce the problem in a clean browser profile before escalating to IT.
What Else Commonly Blocks HubSpot Tracking?
CSP is the sneakiest blocker, but not the only one. Consent management platforms delay or suppress the tracking script until a visitor accepts cookies — correct behavior, but it looks like a tracking failure if nobody remembers the banner exists. Ad blockers and privacy-focused browsers kill HubSpot requests for a slice of your audience no matter what you configure. Tag manager rules can also misfire: a trigger scoped to the wrong page group, or a tag paused during a site redesign and never re-enabled.
Work the list in order of effort. Reproduce in a clean browser profile with no extensions. Check the consent banner's behavior on first visit. Confirm the tag manager actually fires the HubSpot tag on the affected page types. Only then escalate to the CSP investigation, which needs IT involvement. This sequence saves the most common embarrassment: filing a security change request for a problem that turned out to be your own ad blocker.
How Do You Fix It Without Weakening Security?
The fix is surgical: add the specific HubSpot domains the console identified to the relevant CSP directives, rather than relaxing the policy broadly. A typical change touches script-src for the tracking file and connect-src or img-src for the analytics endpoints. Keep the allowlist tight, document what each domain does, and record who approved it.
Expect a process, not just an edit. In regulated organizations, CSP changes usually require security review or compliance sign-off, and the policy may be managed centrally alongside single sign-on and device policies. Bring three things to that conversation: the console evidence, the exact domains to allow, and the business reason — marketing attribution and form analytics are revenue infrastructure, not vanity tooling. Frame it that way and the approval moves faster.
After the change, verify end to end: load pages in a clean browser, confirm the console is quiet, submit a test form, and watch the visit and submission appear in HubSpot. Then set a calendar reminder — CSPs get tightened during security initiatives, and tracking breaks again quietly.
Who Should Own the Fix?
CSP changes sit at the intersection of three teams. Marketing owns the business case and the verification that data flows afterward. Web or IT owns the policy file itself. Security or compliance owns the approval. Assign one person to shepherd the change through all three, because cross-team requests die quietly in shared inboxes. A concise ticket — the console evidence, the exact domains, the business impact, and a rollback note — typically moves faster than a meeting.
How Do You Prevent Recurrence?
A CSP fix holds only if the next website change does not silently undo it. Add the tracking domains to your CSP documentation with a note explaining why each is allowed, so a future security review does not strip them as unknown entries. If the site is rebuilt, moved hosts, or put behind a new CDN or WAF, put CSP verification on the launch checklist alongside forms and analytics — re-testing the tracking code takes two minutes in a browser console. Teams with frequent deployments can go further: a lightweight monitoring check that loads a key page and asserts the HubSpot script executes will catch a regression the same day instead of at the next traffic review. The recurring pattern behind most tracking outages is not a bad policy but an undocumented one. When the policy, its owners, and its exceptions are written down, the next fix is a ticket instead of an investigation.
How Vantage Point Helps
Vantage Point implements HubSpot tracking, forms, and attribution in security-conscious environments, including the coordination with IT and compliance teams that CSP changes require. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Tracking Code Installed but Data Missing?
Vantage Point can diagnose the block, prepare the allowlist request your security team needs, and verify the data flow end to end. Talk to Vantage Point about HubSpot tracking.
Frequently Asked Questions
What is a Content Security Policy?
A Content Security Policy is a browser-enforced security header that lists which domains may provide scripts, styles, images, and connections for a website. It prevents injected or unauthorized code from running, and it blocks legitimate third-party tools until their domains are explicitly allowlisted.
How do I know if a CSP is blocking my HubSpot tracking code?
Open the browser developer console on your live site and look for errors such as "Refused to load the script" that name a HubSpot domain and cite a Content Security Policy directive. Those messages confirm the policy, not the snippet, is the problem.
Does Google Tag Manager get around a Content Security Policy?
No. Tag managers are third-party scripts too, so a strict CSP blocks the tag manager itself, and tags inside it still need their own domains allowlisted. The policy must permit each script and endpoint, however it is delivered.
Which HubSpot domains need to be allowlisted?
The exact set depends on which HubSpot tools you use — tracking, forms, chat, and meetings can use different hosts. Let the browser console tell you: each violation error names the blocked domain, and your HubSpot implementation partner can map those to the services involved.
Is it safe to allow HubSpot domains in a CSP?
Allowlisting specific, documented domains for a tool your organization has chosen is normal practice and very different from loosening the policy broadly. Add only the required domains, document the business purpose, and route the change through your usual security review.
Why did HubSpot tracking work before and stop suddenly?
CSPs change. A security initiative, a site migration, or a new tag manager rule can tighten the policy without marketing hearing about it. If tracking worked previously, ask IT what changed and re-check the console for newly blocked domains.
