Security & Privacy

Data Protection

• All data encrypted in transit using TLS 1.2+ (HTTPS enforced on all endpoints)
• All data encrypted at rest using AES-256 via our database provider
• Database hosted on Supabase (built on PostgreSQL) with automated backups
• API endpoints enforce payload size limits (50KB) to prevent abuse
• Rate limiting on all public endpoints (events API: 100 req/min per API key; AI endpoints: 20–50 req/hr per authenticated user, 10/hr for anonymous support chat)
• Atomic rate limiting via Postgres transactions with fail-closed behavior — service errors block requests rather than bypassing limits
• AI spend capped at $200/month via automated circuit breaker to prevent runaway costs from compromised credentials
• Email unsubscribe links use HMAC-SHA256 signed tokens to prevent enumeration attacks

Tenant Isolation

Every customer's data is logically isolated using PostgreSQL Row-Level Security (RLS) policies. Each API request is verified against project ownership before returning any data.

• Row-level security enforced at the database layer — not application-level checks that can be bypassed
• Shared authentication helper (requireProjectAccess) verified on every endpoint
• Build-time CI check prevents any new endpoint from bypassing the isolation helper — the deploy fails if the rule is violated
• Cross-tenant data access is structurally impossible, not just policy-prohibited
• Superadmin access restricted to a single whitelisted email with audit logging on every request

Authentication & Access

• Login via Google OAuth or magic link (no passwords stored)
• Session tokens issued by Supabase Auth with JWT verification
• API keys scoped per project, never shared across accounts
• XSS protection: all user input sanitized before storage (HTML tags stripped, entities escaped)
• CORS configured to allow only the onboardics.com origin
• Security headers enforced: HSTS (max-age 63072000), CSP frame-ancestors 'self' directive (modern W3C standard replacing legacy X-Frame-Options header), X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restrictive, Content-Security-Policy with explicit allowlists

Compliance

Onboardics is designed with privacy by default.

• GDPR compliant — we provide a Data Processing Agreement (DPA) for customers who need one
• CCPA compliant — we do not sell personal data
• Data deletion requests honored within 30 days. Contact tyler@onboardics.com
• Cookie consent integration via Termly — works with your existing consent management platform
• Tracking snippet exposes a setConsent(true|false) hook for direct consent management platform integration. Default behavior honors navigator.globalPrivacyControl. Call window.__onboardics.setConsent(false) on consent banner decline (or GPC signal) to stop all tracking. Termly is auto-detected and wired automatically — if you use Termly, you don’t need to write any consent integration code; the snippet reads Termly’s analytics consent from localStorage on load and re-checks every 30 seconds for mid-session changes. Cookiebot and OneTrust currently require manual setConsent() wiring; auto-detection for those is on the roadmap. Custom consent flows are always supported via the same hook.
• Zero cookies — the tracking snippet stores session state in localStorage only, never in cookies. Simplifies your cookie policy disclosure.
• Subresource Integrity (SRI) — for customers with strict content security requirements, we publish an immutable hashed URL of the tracking snippet at /v1/<hash>.js alongside the canonical /v1.js. The current hash plus paste-ready integrity="sha384-..." attribute is available as JSON at /v1/manifest.json. Use the hashed URL with SRI in your <script> tag to pin to exactly this byte sequence and have the browser reject any tampered load.
• Automatic JS error capture with PII redaction (default on, opt-out via setErrorCapture(false)). Before any error data leaves the browser, a 9-pattern redaction chain strips Bearer tokens, provider API keys (sk_test_…, pk_live_…), URL query-string secrets (password, token, api_key, auth, secret, credentials, session, bearer, jwt), email addresses, UUIDs in URL paths, long numeric IDs in URL paths, credit-card-like digit sequences, phone numbers, and Mac/Linux home-directory paths (/Users/…, /home/…). Capped at 10 error events per session, deduplicated by message+file+line+column. Error capture inherits the consent gate — when setConsent(false), error events are not emitted either.
• Form-field-name denylist redacts common PII field names before emission (ssn, credit, cvv, card, password, token, secret, api_key, auth, bank, routing, iban, passport, license, taxid). We never capture form values — only interaction events (focus, blur, submit) with the field name and form ID.
• Bot traffic is flagged at the event metadata level (_bot: true) not client-side-dropped. Preserves evidence so dashboards can filter or include bot traffic at read time — no silent data loss that would hide data-quality issues like crawler floods or headless-browser monitoring.
• Data retention policies enforced per plan tier (30 days Free/Starter, 90 days Growth, unlimited Scale/Business)
• Post-cancellation data retained 30 days for reactivation, then permanently deleted

What We Explicitly Do NOT Have

Not yet in place: SOC 2 Type II certification (targeting Q4 2026), HIPAA BAAs, SAML SSO, customer-facing audit log exports, formal third-party penetration testing. If any of these are blockers for your evaluation, email tyler@onboardics.com and we'll discuss your timeline.

SOC 2 Type II

We are pursuing SOC 2 Type II certification. Our target completion is Q4 2026. In the meantime, the controls described on this page — tenant isolation, encryption, access controls, audit logging, and CI-enforced security checks — reflect the operational practices that SOC 2 evaluates.

If you need a security questionnaire completed before your evaluation, contact tyler@onboardics.com and we'll respond within 48 hours.

Pin a specific snippet version (SRI)

Why: if your compliance program requires subresource integrity on third-party scripts, or your audit process needs a verifiable record of exactly which bytes run on your site, Onboardics publishes every snippet release at an immutable, content-addressed URL with a SHA-384 integrity attribute. The browser refuses to execute the file if even one byte has changed.

How: fetch the current hash and integrity string from our manifest:

curl https://onboardics.com/v1/manifest.json

The manifest returns { url, integrity, sha384_hex, size_bytes, generated_at }. Paste the url and integrity into your install tag:

<script
  src="https://onboardics.com/v1/<hash>.js"
  integrity="sha384-<base64>"
  crossorigin="anonymous"
  data-key="YOUR_KEY"
  async></script>

Trade-off: pinning means the byte sequence you audited stays verifiable — but it also means you won't receive snippet updates until you rotate the hash. When we ship a new snippet, the old hashed URL stays up for a grace period and then 404s, so pinned installs break loudly rather than silently diverging. The canonical /v1.js install (without SRI) always works and always gets the latest bytes.

Roadmap: we're planning an opt-in webhook + email notification when we publish a new snippet version, so pinned-install customers can queue the update ahead of the old URL expiring. Email tyler@onboardics.com if this would be useful for your team — we prioritize features customers ask for.

Report a Vulnerability

If you discover a security vulnerability in Onboardics, please report it responsibly to tyler@onboardics.com. We take all reports seriously and will respond within 48 hours.

We do not currently offer a formal bug bounty program, but we appreciate and acknowledge responsible disclosures.