Browser SDK security

What the SDK does

The FirstDistro SDK is a small script your team adds to your web application. It sends product usage events (what you choose to track) to FirstDistro so features like customer health and insights reflect real behavior—not only CRM data.

You can install it via our npm package or a hosted install flow. Setup guidance lives in our Getting Started documentation.

What runs in the browser vs on FirstDistro

• In your users' browsers: the SDK loads, reads remote configuration, associates events with the user and account identifiers you provide, queues events, and sends them to FirstDistro over HTTPS.
• On FirstDistro servers: we receive those events, validate them, store them for your workspace, and use them for the product features you subscribe to—under the same tenant isolation and security practices described on our main Security page.

How the product connects (plain language)

When you use our recommended installation token, the SDK contacts FirstDistro over HTTPS to complete setup. Your app then uses that setup to load SDK settings and send batches of events to FirstDistro. Connections use TLS (encrypted in transit), consistent with our platform-wide data protection commitments.

For technical reviewers: configuration is fetched from /api/vendors/…/sdk-config using your workspace credentials after setup; events are sent to /api/tracking/events/batch.

What data typically leaves the user's device

Each event your code records can include a name, optional custom fields you supply, and technical context the SDK attaches automatically so we can understand usage in context.

Treat custom properties as your responsibility: do not send passwords, secrets, payment card data, government IDs, or other highly sensitive categories you would not put in application logs.

Optional storage in the browser

By default, the SDK may persist identifiers and traits you set (for example user and account context) in the browser's local storage so sessions feel consistent across visits. You can turn persistence off in SDK configuration if your policy calls for it.

A separate session identifier may be stored for the browser tab in session storage so we can group events for analytics.

When the user leaves a page (unload)

Browsers limit what scripts can do when someone closes a tab. In those cases the SDK may use the browser's "best-effort" send path, which cannot always set the same headers as a normal request. Our server accepts a carefully scoped payload so events are not silently dropped. Your security team can inspect this behavior in the browser's network tools during integration testing.

Why your own app security still matters

The SDK runs as part of your web pages. If malicious code can run inside your product (a class of issues often discussed under "cross-site scripting" or XSS), it may be able to access anything your legitimate scripts can access in that page context—including data your integration holds in memory for FirstDistro.

FirstDistro does not remove the need for secure engineering practices on your side: patching vulnerabilities, reviewing dependencies, and using browser security features (such as content security policies) where appropriate for your stack. Our platform security overview describes how we protect data once it reaches FirstDistro—see Security at FirstDistro.

Privacy and agreements

How we handle personal data at the platform level is described in our Privacy Policy. Enterprise customers can discuss data processing agreements and security questionnaires with our team using the contacts on our Security page.

What we're improving

We continue to refine how browser credentials are scoped and presented so security reviews are straightforward—without changing the fundamental fact that any in-page SDK depends on the host app staying safe. Ask your FirstDistro contact for the latest roadmap detail if this is part of your procurement process.