Security at Torva

One store cannot see another

This is the control everything else rests on, so it is worth being precise about how it works.

Tenant isolation in Torva is enforced by the database, not by application code remembering to add a filter. Every table in Torva’s database has PostgreSQL row-level security enabled — there are no exceptions — and the policies decide which rows a signed-in person can see from their membership of that workspace and their role in it. A query that forgot its where clause returns nothing, rather than returning somebody else’s store.

The signed-in database role can write directly to only a handful of tables. Everything else goes through reviewed database functions that check the caller’s role before they change anything, which keeps authorisation in one reviewed place instead of spread across every route.

The anonymous role — what an unauthenticated visitor to a storefront gets — has read access to only the small set of tables a public store page must read, and even there row-level security decides which rows.

The whole-store export is the clearest illustration: it reads through the requester’s own session rather than an administrative key, precisely so that isolation is decided by the same rules as everywhere else instead of by that one route getting it right.

Accounts, roles and two-step verification

• Sign-in is handled by a managed authentication service. Passwords are stored as hashes by that service; Torva never sees or stores a password.
• Two-step verification uses an authenticator app (TOTP) and is available on every account. An owner or admin can require it for the whole workspace, so a team cannot be as weak as its least careful member.
• Access is by role — owner, admin, staff and partner — and the role is checked in the database, not in the browser. Actions like exporting the whole store or changing billing are owner and admin only.
• Team invitations are single-use, time-limited and bound to the workspace that issued them.

Credentials and secrets

• Provider credentials a merchant stores — payment gateway keys, carrier keys, tracking credentials, connected-account tokens — are encrypted with AES-256-GCM before they are written, using a key held in the deployment’s environment rather than in the database.
• API keys Torva issues are stored as hashes; the key itself is shown once, at creation, and cannot be retrieved afterwards.
• Card numbers never reach Torva. Subscription checkout happens on the billing provider’s own page, and a customer’s card at a merchant’s checkout goes to that merchant’s processor.
• The whole-store export deliberately excludes secrets: sealed provider credentials, key material, webhook signing secrets and session records stay where they are.

Traffic between Torva and everybody else

• Everything is served over HTTPS, including every merchant storefront on its own custom domain; certificates are issued and renewed automatically.
• Every inbound webhook — billing, payments, email delivery, shipping, messaging — is verified against its provider’s signature before it is acted on, using a constant-time comparison.
• Billing events are recorded by their provider id before they are applied, so a replayed or duplicated event cannot charge, upgrade or cancel a store twice.
• Outbound requests to providers carry explicit timeouts, so a hanging third party degrades one feature instead of the site.

What leaves Torva when something breaks

Error monitoring is where platforms quietly leak customer data, because the default in every error reporter is to attach the request that failed. Torva’s reports are built from an allowlist instead: an outbound error report contains a hash of the stack frames, a severity, a timestamp and which deployment it came from. The request, its headers and body, the original error message and any user fields are removed before the report is sent.

That makes an error report less useful to debug from, and it is the right trade: a report cannot leak what it never carried.

Your data: take it, or delete it

• Export. Settings → Advanced writes your whole store to one file: products, variants, documents, inventory, customers, notes, orders, order items and events, fulfilments, discounts, affiliates, commissions, support conversations, setup and webhooks. It is paged until it genuinely reaches the end, because a truncated export that looks complete is worse than an error.
• Erase one person. A merchant can honour a deletion request without emailing us. The customer record, their consent record and the contents of email sent to them are deleted; their orders are anonymised, keeping the number, the money and the country and region that make them a tax record, and losing the name, email, phone, street and notes. It is irreversible, and the screen says so before it runs.
• Proof. Each erasure is logged with the subject stored as a one-way hash, so the record proves the erasure happened without preserving the address it erased.

Availability and recovery

The application is served from a managed global edge platform. The database is managed PostgreSQL with the provider’s automated backups; daily backups are kept for seven days on our current plan.

A subscription ending, a payment failing or a suspension never deletes data: those take a storefront offline and leave the workspace intact. Merchant data is kept for at least 90 days after a subscription ends so it can still be exported.

We do not offer a contractual uptime guarantee or service credits today, and we would rather say so than imply one.

How we build

• Every change runs through an automated suite covering tenant isolation, permissions, compliance rules and the storefront before it can ship.
• Secrets live in the hosting platform’s environment configuration, never in the repository. Deploy tooling asserts that a local environment file cannot be copied into a build.
• The staging and production deployments are distinguished by a single declared origin, so a preview cannot be indexed, cannot send live email and reports its errors as staging.

What we do not claim yet

Torva is a new platform, and this is the honest list:

• No SOC 2, ISO 27001 or PCI DSS attestation. Card data is handled by our providers, which is why PCI scope stays with them, but we have no audit report to show you.
• No third-party penetration test yet, and no public bug bounty.
• No contractual uptime guarantee or service credits.
• No signed data processing agreement offered as standard yet. If you need one, email us and we will work through it.
• No cookie consent banner on torvaos.com. Analytics and session replay load on public marketing pages without asking first; see the privacy policy for what that means and how to opt out.
• We will update this section as each of these changes, rather than removing it.

Reporting a vulnerability

Email support@torvaos.com with “Security” in the subject. Tell us what you found and how to reproduce it; we will acknowledge within two business days and keep you posted until it is fixed.

Please test only against your own store or a free preview you created. Do not test against another merchant’s store, do not attempt to access data that is not yours, and do not run load or denial-of-service tests. We will not pursue anybody who reports a genuine issue in good faith within those limits.