Security, with the useful details

This describes implemented application controls, not a security certification or a completed production audit. See hosting and retention for the service boundaries and service status for incidents.

Separate trust boundaries

The browser SDK uses a public site identifier. Public identifiers are routing information, not secrets. Browser collection requires an allowed origin, but an Origin header is not proof of a human visitor and can be forged outside a browser. Rate limits and quotas limit abuse; they cannot make public analytics immune to fabricated traffic.

Server-side ingestion requires a hashed, revocable API key scoped to one site. Console requests require an authenticated session and site access checks. Owning one site does not grant access to another site in the same organization.

Team sessions and secrets

Hosted console cookies are secure and HttpOnly. Refresh credentials rotate, and replay revokes the affected session. Email verification, Google OAuth, and authenticator-app TOTP are supported. The fixed preview login is restricted to local development.

Minimize what arrives

Visitor SDK requests omit credentials. Event requests suppress the HTTP referrer header; the optional rules request may send the origin only. Bounded campaign tags are automatic in SDK 1.0.3; arbitrary query parameters and fragments are excluded by default. Raw IP addresses are not stored in analytics facts. Pseudonymous identifiers and customer-supplied event data can still be personal data.

Operational responsibilities

Production TLS, exact trusted-proxy configuration, restricted database access, secret rotation, tested backups, monitoring, and incident response need deployment evidence. Code cannot certify that an operator actually ran a restore drill.

Report a vulnerability privately or read the architecture and privacy controls.