Legal
Security
Last updated: 31 October 2026
This page describes controls that are implemented and tested in the product today. VividProp holds no SOC 2 or ISO 27001 certification, and nothing here should be read as one.
1. Workspace isolation
Every protected request resolves the session server-side, re-reads live membership, checks the role permission, and only then applies the organisation scope. An organisation identifier sent by the browser is never trusted. Repository functions take the organisation as an argument and put it in the query, so a cross-workspace read returns nothing rather than someone else's row. Each repository has a test that asserts the denial.
2. Credentials
Passwords are hashed by Better Auth and never stored or logged in clear. Email verification is required before the first session. Passkeys (WebAuthn) are supported for sign-in: only the public key is stored, the relying party is bound to the application origin, and the signature counter rejects a cloned authenticator. Google sign-in is available when the deployment has OAuth credentials configured.
3. Uploads and media
Photo uploads use a short-lived signed URL minted server-side, bound to the property and to an exact byte length and content type. On finalisation the object is re-read, re-encoded, stripped of EXIF metadata and hashed. Downloads are served only through an organisation-scoped row; there is no public object listing.
4. Provider keys
Inference keys live server-side. A key entered by staff is encrypted at rest with AES-256-GCM and shown only by its last four characters; a key that cannot be decrypted fails closed rather than falling back to an environment variable. Keys never reach the browser bundle.
5. Webhooks and API keys
Outbound CRM webhooks are signed with HMAC-SHA256 over the canonical body and retried with backoff; failed deliveries are parked and visible in the workspace log. API keys are workspace-scoped, stored hashed, shown once, and revocable.
6. Backups
The database is dumped nightly, verified with a restore listing, encrypted before it leaves the host, and copied off-site with a read-back checksum comparison. A restore drill runs against a throwaway database and asserts schema, migrations and row counts.
7. Reporting a vulnerability
Email [email protected] with the affected surface and a reproduction. We acknowledge receipt, tell you what we found, and credit you if you want to be credited. Please do not test against another customer's workspace or run destructive load against production.