Security

How Your Data Is Protected

UserContext handles interaction data from our customers' users. This page describes the concrete controls in place today. Where a control belongs to an infrastructure provider, we say so.

Will It Slow Down or Break Your Site?

The pixel is one defer-loaded script (~26 KB gzipped) that never blocks rendering, does no heavy main-thread work, batches its requests, and injects no visible UI (zero layout shift). On the reliability question that matters most for a revenue-generating site: a malfunction in the pixel can, at worst, stop the pixel. It cannot break your site's own code.

• It does not patch fetch or XMLHttpRequest — your network layer is untouched.
• The one browser API it augments (the SPA history API, to see client-side route changes) runs your navigation first and unconditionally, then defers its own work to a separate task — so a pixel error cannot reach your router.
• All internal work is wrapped in error guards, and it is a separate deferred script, so a load or parse failure has no effect on your page.

The full, readable source is published at /tracker.js so your team can verify all of this line for line.

Encryption and Infrastructure

Traffic between the tracker, our API, and the dashboard uses TLS. Data is stored in PostgreSQL hosted by Supabase on AWS, with provider-managed encryption at rest and automated backups. The application runs on Railway and Vercel.

What Never Reaches Our Servers

Personal data is stopped at three layers, none of which a site can turn off:

• The pixel never records what a visitor types. No keystroke capture, and it never reads a text field's value. It takes a field's accessible label, not its contents, and skips password, email, tel, and credit-card fields entirely.
• A server-side deny-list strips known personal fields (email, name, phone, address, SSN, card, passwords, tokens) from every event before storage.
• URLs are scrubbed at ingest — emails anywhere in a path or query, and the values of secret-named parameters, are redacted before the URL is stored, so they never reach the reports either.

Also: session recording is off by default, arms per-flow only, masks all input values in the browser, and lets visitors opt out; voice audio is discarded after transcription.

Access Controls

• API keys: stored as SHA-256 hashes. We cannot read them back.
• Row-Level Security (RLS): every database query is scoped to the authenticated project, enforced in the database rather than in application code.
• Separation of duties: service-level operations use separate credentials from user-level operations.

Every Read Is Logged

Each read of customer data through the API surface is written to an append-only access log: the endpoint, the key that made the request, a salted hash of the caller's IP, and the timestamp. IP addresses are stored only as per-site salted hashes, never raw. The logs themselves are retention-limited and purged on schedule.

Origin Validation and Abuse Controls

Ingestion endpoints validate and monitor request origins against a per-site allow-list, and rate-limit by IP before any processing or AI spend happens.

Compliance

GDPR and CCPA rights are supported by working mechanisms: subject-scoped deletion, data export, and the retention controls described in our Privacy Policy. A data processing agreement is available on request. Our infrastructure providers, Supabase and AWS, maintain SOC 2 Type II certification.

Incident Response

In the event of a security incident, we follow a structured response process:

1. Detection: monitoring and alerting identify potential incidents
2. Containment: affected systems are isolated to prevent further impact
3. Investigation: analysis to determine scope and root cause
4. Notification: affected customers are notified without undue delay, within the timelines required by applicable law
5. Remediation: fixes and preventive measures are implemented
6. Post-mortem: a written analysis is shared with affected customers

Responsible Disclosure

We welcome security researchers to responsibly disclose vulnerabilities. If you discover a security issue, please report it to:

security@usercontext.com

Please include a detailed description of the vulnerability, steps to reproduce, and any potential impact. We commit to acknowledging reports within 48 hours and providing regular updates on remediation progress. We will not take legal action against researchers who follow responsible disclosure practices.

Contact Our Security Team

For security questions, vulnerability reports, or compliance inquiries:

UserContext, Inc. Security Team
Email: security@usercontext.com