Security

Version 1.0, approved 2026-09-21. Every control below is one that exists in the code today; nothing is described that is planned but not built. eScryber holds no security certification and this page does not claim one.

The short version

• Your organisation's data is isolated from every other organisation's at the database query level: every request is scoped to one organisation, and a request for something another organisation owns gets "not found", not "forbidden".
• Every action on a document is written to a hash-chained audit trail; every privileged action by an eScryber operator is written to a second, separate hash-chained log that is verified daily.
• Passwords are hashed; integration tokens are encrypted with a key that is not in the database; card details never touch our servers.
• Every request body, upload, and expensive operation is bounded before it is allowed to consume resources.

Access

Accounts. Sign-in is by password (hashed with scrypt through Better Auth) or by a 15-minute magic link. Two-factor authentication (TOTP with backup codes) is available to every account. Sessions last up to 30 days and record the IP address and browser for the account holder to review. Where an operator has enabled it, an account can also be opened with a HyperChimp account: HyperChimp confirms who signed in, eScryber issues its own session, and an address that already belongs to an eScryber account is never linked without a code sent to that address. A HyperChimp link can be removed from Settings → Security as long as a password or a recent magic link still lets the person in; two-factor authentication is still asked for on every sign-in, whichever way it starts.

Roles. Each organisation has owners, admins and members. Owners and admins manage people, billing, integrations and exports; members work with documents. API tokens carry explicit scopes and are stored only as hashes. Some actions — requesting a data export, submitting nonprofit verification — are deliberately unavailable to API tokens.

Recipients are authorised by a signing link containing a random token. Only the token's hash is stored; the token is rotated when a reminder is sent; each link is tied to one recipient on one document.

Operators. eScryber staff have a separate administrative surface. Every privileged action there requires a stated reason and is written to an append-only, hash-chained log; the chain is re-verified every day and a broken chain pages the on-call person and is treated as a security incident.

Tenant isolation

Every route resolves the caller's organisation from their session or token and scopes every query to it. There is no organisation identifier in URLs to tamper with. A recurring test suite exercises every route with a caller from a second organisation and asserts that nothing of the first is revealed — by status code, by body, or by timing of a paid operation.

Object storage keys are tracked in a reference ledger that records which organisation owns each object; a scheduled audit looks for any object claimed by more than one organisation.

Data protection

In transit	TLS terminated at the reverse proxy (Caddy); the proxy also enforces the maximum request size
Passwords	One-way scrypt hash
Two-factor secrets	Stored for verification only; never displayed after setup
Integration tokens (Microsoft, DocuSign)	AES-256-GCM, key held only in the server environment — a database copy alone does not yield the tokens
Webhook secrets	Stored to sign outgoing deliveries; excluded from every export
At rest	Database and object-store encryption are properties of the deployment host and storage service, recorded in the continuity policy
Card data	Never stored or transmitted through eScryber; Stripe-hosted pages only

Document integrity

• Every uploaded PDF is validated by its bytes, not its declared type; markup hidden inside a PDF is rejected; object counts and archive sizes are bounded before parsing.
• Every completed document's certificate of completion prints a SHA-256 of the signed content taken before the certificate pages and any seal were appended — labelled as such, because it is not the hash of the file you download. The file as stored has its own digest, recorded separately, which our verification compares the stored file against.
• Per-document audit events are hash-chained: each event's hash includes the previous event's hash, so an altered or removed event breaks the chain, and the certificate records the final hash and chain length.
• Where the operator enables it, completed PDFs are also cryptographically sealed: a detached PKCS#7 signature under the operator's certificate, without a trusted timestamp. The certificate of completion states whether one is present and what it is; a visual seal alone is not a cryptographic one. How a given PDF reader displays the seal depends on that reader's trust settings, not on eScryber.

Limits and abuse resistance

• Per-user, per-organisation, per-recipient-domain and per-IP rate limits on sending, reminders, signing and public forms.
• Storage allowances per plan, enforced by reserving space before an upload is accepted.
• Concurrency leases so that one organisation's expensive work cannot crowd out another's.
• Kill switches for each expensive capability, enforced at request time and in background workers, with every change recorded with a reason.
• Request idempotency keys so a retried request does not repeat a charge or a send.

Logging and monitoring

Application logs are redacted before they are written: credentials by key and by pattern, signing tokens in URLs, and document content are removed. Metrics carry no identifiers. Worker liveness is written to the database and checked by an independent evaluator; a dead worker, a stalled queue, a broken audit chain, or a verification backlog pages the on-call person.

Software supply chain

Dependencies are pinned and checked in continuous integration; every change runs lint, type-check, unit and integration tests, a migration check from an empty database, and a container build before it can merge. A dependency remediation log is kept.

Vulnerability reporting

If you find a security problem, tell us at security@escryber.com. We will acknowledge within two business days, keep you informed, and not take action against good-faith research that respects other users' data. The incident response policy says what happens next.

What we do not claim

• No third-party certification (SOC 2, ISO 27001) has been obtained. A scoped external review of tenant isolation and the signing/authentication path is planned before the first pilot organisation signs a real document; its outcome will be summarised here.
• Backups and restoration drills are being established (see continuity); until a drill has been run, no recovery time is promised.
• Nothing is perfectly secure. This page describes controls, not guarantees.

Contact

security@escryber.com