Security

The Varni runs the operational backbone of small food businesses — subscriber lists, menus, orders, payments, delivery routes. We treat the data you trust us with as if it were our own. The controls below describe the technical and organisational measures we apply across the platform.

• Hosting.Application code runs on Vercel's serverless platform, with traffic served from a global edge network and origin compute in the United States.
• Database. Our primary database is managed PostgreSQL on Neon, hosted in the US-East AWS region. Storage is encrypted at rest; connections are encrypted in transit with TLS 1.2+.
• Backups. Neon provides continuous point-in-time recovery. In addition, paid plans receive automated daily logical backups stored in encrypted object storage.
• Tenant isolation. Every Customer (Kitchen Owner) is mapped to a dedicated tenantId. Every database query is constrained by that tenant ID, and JWTs are cross-checked against the request host so a token issued for kitchen A cannot be replayed against kitchen B.

• In transit. All client and server traffic is served over HTTPS with TLS 1.2 or higher. HTTP requests are 308-redirected to HTTPS at the edge. HSTS is enabled with a two-year max-age and includeSubDomains.
• At rest. Database storage, object storage, and backups are encrypted at rest using AES-256.
• Secrets. Application secrets (database URLs, API keys, JWT signing keys) are stored as encrypted environment variables in Vercel and are never committed to source control.

• Subscriber sign-in. Subscribers authenticate with a one-time passcode delivered via WhatsApp or email. OTPs expire after a short window and are rate-limited per phone number and per IP.
• Kitchen Owner sign-in. Owners can sign in with email + password or Google Sign-In (OAuth 2.0). Sessions are JWT-based, scoped to a single tenant, and stored in HTTP-only secure cookies.
• Role-based access. Every API route is gated by a role check (Subscriber, Driver, Admin, Super Admin) and by a tenant guard that fails closed when the tenant context is missing.
• Internal access. Only a small number of named engineers can reach production. Production access is via individually-issued credentials, requires multi-factor authentication, and is logged.

All card processing is handled by Stripe, which is PCI-DSS Level 1 certified. Card data is collected directly by Stripe's elements in the user's browser; full card numbers, CVCs, and expiry dates never touch our servers or logs. We only persist Stripe's opaque customer and subscription identifiers.

• Strict HTTP security headers on every response — X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a restrictive Permissions-Policy.
• Input validation at every system boundary; parameterised queries via Prisma ORM (no raw string interpolation).
• Webhook signatures verified for Stripe, Zernio, and other inbound integrations.
• Dependency vulnerability scanning runs on every push, and patch updates are applied on a regular cadence.

We collect application logs and performance metrics through Vercel and our database provider. Logs are retained for a limited window and are scrubbed of one-time codes, full card numbers, and other sensitive material before they leave the application boundary.

We aim to confirm receipt of any reported security issue within one business day, triage it within three, and remediate confirmed vulnerabilities on a timeline proportional to severity. If an incident affects Customer Data, affected Customers will be notified without undue delay and, where required by law, within 72 hours of becoming aware of the breach.

We welcome reports from security researchers. Please email info@thevarni.com with a description of the issue, reproduction steps, and any relevant logs. Please do not publicly disclose the issue until we have had a reasonable opportunity to address it.

For security-related questions or to request additional documentation (DPA, security questionnaire), email info@thevarni.com.