Security posture
Privara Vault aligns with layered defense practices: HTTPS everywhere for marketing and app shells, cryptographic controls for selective vault payloads, database row-level security isolating tenants, audited API validation, Stripe signature verification on billing hooks, defensive HTTP headers emitted from our edge middleware, and least-privilege service-role usage limited to narrowly scoped reconciliation jobs on the backend.
Separation & storage
- Operational data stays within Supabase projects with enforced RLS keyed to authenticated users.
- Sensitive vault payloads are designed to reside as ciphertext envelopes when passphrase flows are exercised — plaintext fields exist only where users explicitly opted into simpler onboarding during early phases and should be tightened with encryption migrations per household policy.
- Backups inherit the same provider controls you configure in Supabase + object storage settings.
Authentication & sessions
Supabase Auth issues short-lived access tokens stored in secure cookies for server components. Session fixation and cross-site requests are mitigated using modern browser defaults plus Privara's explicit cookie configuration and proxy headers.
First responder share links
Optional /first-responder/[token] pages surface only emergency-oriented fields (never full vault documents). Tokens are long random strings stored server-side; rotate them if a link is overshared. Anyone with the URL can read the limited snapshot — treat it like a medical bracelet: useful, but not secret.
Responsible disclosure
Found a vulnerability? Email support@privaravault.com with encrypted details if possible. We commit to timely triage and coordinated disclosure for validated issues.
Continuous improvement
Security is iterative. Review /security for our customer-facing narrative and subscribe to platform status from your infrastructure vendors.