Security

Connections and certificates

Every request to the Crate dashboard, to the marketing site and to every merchant storefront is served over HTTPS. Certificates are issued automatically, including for merchant custom domains, so a merchant who points their own domain at Crate gets TLS without asking anybody for it.

The application sets Strict-Transport-Security, including on subdomains, and marks its session and remember-me cookies Secure, so neither is carried over a plaintext hop by an edge or a proxy. Session state is signed and encrypted in the cookie rather than looked up from a shared store.

What is encrypted, and what is not

Encrypted in transit: everything, as above.

Encrypted at the application layer, with AES-256-GCM through Active Record Encryption: payment gateway secrets, outbound mail credentials, the private keys used to sign a merchant's own sending domain, and third party integration API keys. These are the values a stolen database copy would otherwise make immediately usable, so they are encrypted with keys that do not live in the database.

Never stored in a form anybody can reverse: account passwords, which are hashed. Older accounts carry a legacy salted SHA-512 digest and are re-hashed with bcrypt the next time their owner signs in successfully, so the population converts as it is used rather than in a migration nobody can verify.

Not encrypted today: the underlying disk. The production host runs an ordinary unencrypted filesystem, so full-disk or volume-level encryption is a control Crate does not have. A reviewer asking that question gets a no, and it is listed with the other open items below.

One store cannot reach another

Crate is multi-tenant, which means many independent businesses run on the same infrastructure, so isolation is the control everything else rests on.

Every record that belongs to a store carries that store, and every query the application makes is narrowed to the current store before it runs. That holds on the dashboard, on the storefront and through the API, and it is the same code path in all three, so there is no surface where the rule depends on somebody remembering to apply it.

Storefronts are separated by hostname. A request arriving on a hostname that resolves to no store is refused rather than falling through to whichever store answers first.

Payments and card data

Crate does not store card numbers. There is no column for one. The payment provider a merchant connects captures the card, and what Crate records against an order is the card brand, the last four digits, the expiry month and year, and the provider's own token for the customer and the payment method.

This limits Crate's PCI scope rather than removing it: Crate is responsible for the page the provider's card form is embedded in, and the provider is responsible for the card data itself. Their compliance documentation covers their half, and we will tell you which provider handles which flow if your reviewer asks by name.

Your account, and your staff

Two-factor authentication is available on merchant accounts using a standard authenticator app, with single-use recovery codes issued when it is switched on.

Staff are invited individually rather than sharing one login. Each has a role, roles carry per-permission control over what can be seen and changed, and a member of staff can be suspended or removed immediately.

Sessions time out after thirty minutes of inactivity. An account locks after ten failed sign-in attempts and unlocks after an hour or by email. Sign-in, sign-up, password reset and account confirmation are rate limited per IP address and per email address, so an attacker working through a password list is stopped by the platform rather than by the strength of one password.

Changing a password, completing a password reset, or choosing sign out other devices sets a watermark on the account, and every session created before that moment stops working on its next request. Ending a session actually ends it.

The activity trail

Every action that changes something in a store is recorded, and the records are append-only: the application refuses to update or delete one.

The trail is tamper-evident rather than merely append-only. Each entry carries a SHA-256 digest computed over its own contents and over the digest of the entry before it, so removing or editing an entry breaks every digest after it. Somebody with database access can still change history, but they can no longer change it undetectably, which is the property an auditor is actually asking about. Secrets are redacted out of an entry before its digest is taken, so the trail cannot become a place credentials sit in plain text.

Governance events, meaning who was invited, promoted, suspended, removed, or had their permissions changed, are kept in their own trail as well, so answering who gave this person refund access does not mean reading forty thousand order edits. Those are retained for a year.

What Crate's own staff can see

Access to production systems and production data is limited to the people whose work requires it, granted per person rather than shared, and removed when somebody leaves or changes role.

Where a support engineer needs to look at a merchant's account to resolve a ticket, that access is granted rather than assumed, it is time-limited, and it is written into the merchant's own activity trail, so the merchant can see it happened without asking us.

What Crate's own staff do across stores is recorded in a separate append-only platform trail that the application will not let anybody update or delete.

Where the data is, and who else touches it

The application, the database, the background job queue and uploaded files all run on infrastructure provided by OVH, in the United Kingdom. Merchant and buyer personal data is processed there.

Uploaded files are served through Crate's own domain rather than from a storage hostname, so a merchant's storefront never visibly serves from a shared bucket. Object storage is being moved from the application host to Cloudflare R2, and this page will name the new location on the day it changes rather than in advance of it.

The full list of third parties that touch merchant or buyer data, what each one does and the country it does it in, is published rather than offered on request.

Backups, stated plainly

Crate does not currently keep an off-site copy of the production database or of uploaded files. The data exists on the host that serves it and nowhere else. A total loss of that host would not be recoverable today.

This is the most serious open item on this page and it is being treated as one. The backup script, the retention policy and the restore drill are written and reviewed; what is missing is the off-site destination they write to, and it is being provisioned. Crate is not going to describe that work as done while it is not.

We are telling you this because a security review finds it out anyway, usually by asking for a restore test report we cannot produce, and finding out from the vendor is worth more than finding out afterwards.

Reporting a vulnerability

If you believe you have found a security issue, email [email protected] with enough detail for us to reproduce it. We acknowledge within two business days.

We will not pursue anybody who reports a genuine issue in good faith, gives us reasonable time to fix it before disclosing it, and does not access, change or delete data belonging to a merchant or their customers while investigating. Please do not run automated scans against merchant storefronts: those are other people's businesses, and they did not agree to be tested.