Security & evidence

Trust is a claim. Here is the mechanism.

Certifera exists to answer whether something actually happened, so a vague security page would undercut the product. This is what is implemented today, in specifics — followed by an equally specific list of what is not.

01

Identity and authority

Every mutation has a named actor and a server-enforced role.

Passwords derived with scrypt

64-byte derivation over a per-user random salt, compared with a constant-time equality check. No password ever reaches a log or an error payload.

Sessions are HTTP-only cookies

Not readable from JavaScript, so an XSS foothold cannot exfiltrate a session. Browser operators and agent keys travel on separate paths.

Scoped cfr_ API keys

Four scopes — requests:read, requests:write, proofs:read, proofs:write. Only the SHA-256 hash of a key is stored, and lookups compare digests in constant time so response latency never leaks a partial match.

MFA secrets sealed at rest

TOTP secrets are encrypted with AES-256-GCM under a dedicated field key, so a database read alone does not yield a working second factor.

Roles enforced server-side

Operator, reviewer, relay, and admin checks run inside the route, not in the UI. The console is a view onto the same API, never a privileged path around it.

02

Evidence integrity

Evidence is treated as a claim to be tested, not a file to be trusted.

Declared type is verified against the bytes

The content type is checked against the file's real signature before anything is written. A .pdf that is secretly something else is rejected at the boundary.

SHA-256 on upload

Every asset is hashed as it arrives, and the digest travels inside the proof bundle, so any later substitution is detectable by anyone holding the bundle.

Private by construction

Evidence is never represented by a public URL. Reads require an authenticated, authorized actor, and responses are marked no-store. Object storage writes use AES-256 server-side encryption.

Bounded payloads

An 8 MB ceiling and an empty-file rejection are applied at the boundary rather than after write.

Optional malware gate

A scan webhook can hold proof submission until an asset clears. When the scanner errors, the failure is written as an operational event rather than silently passing.

Absence is a flag, not a pass

Missing capture time, GPS, or device metadata produces a named flag and a lower capture score. Certifera never reads missing signal as evidence of truth.

03

Money movement

Exactly one payout per outcome, guarded in the database rather than in application logic.

Compare-and-set on every transition

A review decision only applies if the outcome is still in review. Two concurrent reviewers cannot both settle or both dispute the same outcome.

One payout, enforced by a unique index

Release is idempotent by construction, not by convention. A retried release cannot double-pay.

Signed, replay-resistant webhooks

Stripe signatures are verified with an HMAC comparison in constant time, and each event id is recorded so a replayed delivery is a no-op.

Out-of-order events cannot resurrect a payout

A late transfer.created arriving after a failure only applies to a payout still authorized; otherwise it is ignored and recorded as an operational warning.

Sandbox by default

Settlement emits a non-financial cert-sandbox- reference unless production credentials are explicitly configured.

04

Auditability

The record is append-only, so history can be read but not quietly rewritten.

An execution ledger per outcome

Every transition — funded, matched, executed, proof submitted, reviewed, authorized, released — writes an immutable lifecycle event.

Audit records on privileged actions

Actor, action, resource, and request context are recorded for administrative and review operations.

Operational events for failures

Scanner errors, unknown-payout webhooks, stale transfers, and SLA breaches are recorded as first-class events rather than console noise.

Rate limits on unauthenticated surfaces

Login, password reset, and other anonymous endpoints are throttled per identifier, and login latency is held constant so it cannot be used to enumerate accounts.

What we do not claim

The absence list.

A security page that only lists strengths is a marketing page. These are the controls Certifera does not have yet. If one of them is a hard requirement for you, that is useful for both of us to know before a pilot, not after.

Full launch readiness plan →
  • SOC 2, ISO 27001, or any completed third-party audit
  • KYC/KYB, sanctions screening, or a published compliance policy
  • Custody or escrow of customer funds
  • A published bug-bounty programme or a formal incident-response SLA
  • Open, self-serve relay onboarding without human vetting

Security questions.

Is evidence uploaded to Certifera publicly accessible?

No. Private evidence is never represented by a public URL. Reads require an authenticated, authorized actor and are returned no-store. When object storage is enabled, assets are written with AES-256 server-side encryption.

How does Certifera prove evidence has not been swapped?

Every asset is SHA-256 hashed as it is uploaded, and that digest is carried inside the proof bundle. Anyone holding the bundle can re-hash the asset and detect a substitution. Separately, the declared content type is validated against the file's real signature before storage.

What stops a payout being released twice?

A unique index guarantees one payout per outcome, and each state transition is guarded by a database compare-and-set. Stripe webhooks are signature-verified, deduplicated by event id, and only applied to a payout still in the expected state.

Is Certifera SOC 2 compliant?

Not today, and we will not imply otherwise. Certifera is controlled-beta infrastructure. Third-party audit, KYC/KYB, and a published compliance policy are explicitly on the pre-production list rather than shipped.

How do I report a vulnerability?

Email the address on our access request form, or open a private advisory on the GitHub repository. There is no paid bounty programme during the beta, and we will say so plainly rather than imply one exists.

Controlled beta

Run your security review before the pilot, not after.

We will answer architecture questions directly and tell you where a control does not exist yet. Certifera is open source — read the implementation rather than take our word for it.