Security

API keys are stored as SHA-256 hashes. The plaintext is shown once, at creation, and cannot be recovered afterwards — not by you, and not by us. A key you lose is replaced, not retrieved.

Passwords use scrypt, which is memory-hard: a leaked user table cannot be brute-forced at GPU speed the way a SHA table can. The cost parameters live inside each hash, so they can be raised later without invalidating anyone's password.

The dashboard never holds an API key in the browser. Pages read a session cookie server-side and forward it. A dashboard that ships a live key to the client is one cross-site scripting bug away from somebody else's credit balance.

Sign-in attempts are limited by address and by account — the per-address limit alone is defeated by having more addresses. Neither locks an account: a limit that locks you out is one somebody else can aim at you deliberately.

Webhook destinations must be public HTTPS addresses. A webhook URL is an instruction to make our servers call an address you choose, which is the shape of every server-side request forgery, so private and link-local ranges are refused.

Retention periods are constants in the source code, imported by the privacy policy from the same place the deletion job reads them — so the document cannot drift away from the behaviour. Erasure is a command we run, not a promise performed by hand against a live database.

Every supplier that sees your data is listed by name, currently 8, with what each one receives.

Email security@proofwire.app. You will get a reply from a person within two working days.

Please give us a reasonable window to fix a finding before publishing it, and we will not threaten you for having looked. Testing against your own account is fine, including the sandbox. Do not test against other people's data, and do not run load tests — the free tools have a rate limit and hitting it is not a finding.

There is no paid bug bounty. Saying so plainly is better than implying one and then arguing about it.

No SOC 2 or ISO 27001. Both are audits of a company, and this one is small and new. If your procurement requires either, we are not a fit yet, and it is cheaper for both of us to know that now.

One shared database per environment, and no read replica. Production and staging are fully separate — separate database, separate API, and preview deployments talk only to staging — but each environment is a single database with no failover. A hosting incident is an outage rather than a degradation.

The status page runs on the same platform as the API. An outage severe enough to take down one can take down the other. It is disclosed on the page itself rather than left for you to discover during an incident.