Skip to main content
Squid ID is built to sit on your site without becoming a liability on it. The SDK runs in an isolated sandbox, is locked to the domains you register, and talks to our servers over encrypted, hardened endpoints. This page covers how that works.

​
If you’re coming from RB2B

Most visitor tools ship a script that runs in the page’s own context. Squid ID isolates the work in a sandboxed iframe and locks the SDK to your domains.
RB2BSquid ID
Execution contextScript in the page contextSandboxed iframe, isolated from your page
Domain lockScript tag on any pageSDK locked to the hostnames you register
Page-level controlLimitedInclusion or exclusion page rules
TransportHTTPSHTTPS with hardened headers and a strict CORS policy

Why this matters. A tag that runs in your page context can read everything on it. Squid ID’s iframe can’t reach into your page, and your page can’t reach into it, so adding Squid ID doesn’t widen your attack surface.

​
Isolated execution

The SDK does its work inside its own iframe, a separate browsing context from your page. The two communicate only through a narrow postMessage channel, with a fixed set of allowed messages. That boundary cuts both ways:
  • The iframe cannot read your page’s DOM, your cookies, your local storage, or any other script on the page.
  • Your page (and anything else loaded on it) cannot reach into the iframe or its data.
So the identification logic is sealed off from the rest of your site. Nothing on your page can tamper with it, and it can’t tamper with anything on your page.

​
Locked to your domains

The SDK is served by a per-website key, and that website is locked to the exact hostnames you register on its URL list. The SDK only runs on those origins, so a key lifted onto another domain simply won’t work. You can narrow it further with page rules to identify on, or skip, specific URLs.
This domain lock is also the most common reason a freshly installed snippet does not connect. If the page serves on a hostname you didn’t register (for example www.example.com when you registered example.com), add it. See Managing websites and Troubleshooting.

​
Encrypted, hardened transport

  • HTTPS everywhere. All traffic is served over TLS. Plain HTTP requests are rejected.
  • Hardened headers. Our API sets a strict set of security headers, including a content security policy.
  • Strict CORS. Cross-origin requests are checked against an allowlist, and requests with a stripped or null origin are refused, which closes a common CSRF vector.

​
Authenticated channels

  • Realtime. The live connection that powers presence and the live feed is gated by a signed token issued per website, so only your authorized SDK can open it.
  • API tokens. Programmatic access uses read-only Bearer tokens that work on GET endpoints only, scoped to your account. See API tokens.

​
What the SDK collects

The SDK gathers anonymous behavioral signals (page views, referrer, basic device and connection data) and sends them to our servers. Identification and enrichment happen server-side, not in your visitor’s browser. How that data is handled, and your responsibilities as the site owner, are covered in Privacy and compliance.