I’m running into a recurring PCI scan failure related to cookies set by HubSpot’s site search functionality and am looking for either a supported remediation path or official documentation I can reference for auditors.
What the scanner is flagging
- Cookie: _pk_ses.*
- Triggered by requests to:
/_hcms/v3/site-search/search?..&autocomplete=true&analytics=true
- Flags missing: HttpOnly (and sometimes Secure, depending on the scanner)
- Classified as: Insecure configuration of cookie attributes
- Severity: Medium (PCI)
What I’ve confirmed so far
- This cookie is set client-side by HubSpot-managed JavaScript
- It appears to be analytics-only, non-authentication, non-session
- No login, payment, or cardholder data exists on the site
- HTTPS is enforced, and “secure cookies only” is enabled at the platform level
- The cookie only appears when site search / autocomplete is invoked (not across all pages)
What I’m trying to determine
- Is there a supported way to disable analytics-related cookies for the HubSpot site search while keeping search functionality?
- Is there official HubSpot documentation confirming that _pk_ses (or related search cookies) cannot be marked HttpOnly due to client-side creation?
- Has HubSpot published PCI guidance or compensating-control language for this scenario that customers can provide to auditors?
Right now, this appears to be expected SaaS behavior rather than a misconfiguration, but I want to confirm whether:
- There is a platform-level setting I’m missing, or
- The correct path is documented exception/compensating control for PCI scans
Hi @ARogers_CMPS — thanks for laying this out so clearly.
I’ll pull in a few folks who are familiar with similar issues. Hey @evaldas, @Christensen , and @GRajput — have you run into PCI scanners flagging HubSpot site search cookies like _pk_ses?
Appreciate any insight you can share — Best, Victor
Hi @ARogers_CMPS
You’ve documented this really thoroughly and your analysis is spot on. The _pk_ses cookie is indeed analytics related (the _pk prefix comes from Piwik/Matomo tracking which HubSpot uses for some search analytics), and you’re correct that it gets set client side by JavaScript.
Heres the tricky part with the HttpOnly flag. By definition, HttpOnly cookies cannot be created or accessed by JavaScript, they can only be set via HTTP response headers from the server. Since HubSpot’s site search sets this cookie client side for analytics purposes, marking it HttpOnly would literally break its functionality. So this isnt a misconfiguration, its architecturally how client side analytics cookies work everywhere. The scanner is technically correct that the flag is missing, but its flagging something that cannot be changed without moving the cookie creation server side.
For your auditors, the compensating control argument is probably your strongest path. The key points would be that the cookie contains no cardholder data or authentication tokens, its scoped to analytics only and doesnt persist session state for anything sensitive, HTTPS is enforced so the cookie travels encrypted, and no payment processing occurs on pages where this cookie is set. You might also try adding analytics=false to your site search requests if you dont need the search analytics, that could prevent the cookie from being created entirely. Worth testing in a dev environment first.
I’d also recommend opening a ticket with HubSpot support specifically asking for PCI related documentation or a statement you can provide to auditors. Theyve likely dealt with this before and may have boilerplate language. At Stacksync we think about compliance requirements a lot when customers are moving data between systems, and having vendor documentation for auditors makes these conversations much smoother. Note: The content is based on my personal experience and was refined using AI for better clarity.
Hope you get this sorted without too much back and forth with the auditors