Security by design, not by promise.
We don't make absolute security claims. Instead we describe, honestly, the controls we implement and the architecture that backs them — so you can evaluate whether Chirograph Verify fits your threat model.
How a request becomes a result.
Each stage is a distinct enforcement boundary; a failure at any stage fails closed.
Technical controls, documented plainly.
WebAuthn at the core
Verification uses the standard WebAuthn API — passkeys and platform/roaming authenticators — with origin and relying-party checks and signature-counter (anti-cloning) validation.
Server-side trust
The browser is never authoritative. Results are validated cryptographically on the server and, for paid access, transactions are re-verified with the provider before any entitlement changes.
Tenant isolation
Tenant identity is resolved server-side from the authenticated API key, session, or internal record — never from client-supplied identifiers. Credentials are highly separated: tenant API key, widget key, admin key, dashboard session.
Credential hashing
API keys, widget keys, and dashboard tokens are stored only as SHA-256 hashes; the plaintext is never persisted or logged.
Dashboard authentication
Customer sign-in is delegated to WorkOS AuthKit (Google or email and a password) through the official SDK; Chirograph never stores or verifies credentials itself. Dashboard sessions are HttpOnly, SameSite=Strict cookies with server-side tenant resolution, and every state-changing action requires a server-bound CSRF token.
Webhook security
Outbound events are signed with HMAC-SHA256 with a stable id; inbound billing webhooks are authenticated by a constant-time signature comparison. SSRF protections pin connections to validated public addresses and never follow redirects.
Rate limiting
Every public surface is rate-limited via Redis-backed fail-closed limiters, separate from billing usage quotas.
Defense in depth
Helmet security headers (HSTS, frame protection, referrer policy, MIME sniffing protection), strict per-page CSPs, per-request correlation IDs, and a PostgreSQL-backed authoritative state layer.
What we don't ship.
Chirograph Verify does not store private keys, biometric data, or raw payment credentials. WebAuthn private keys never leave the user's device; only the non-sensitive public state needed for verification is persisted. Secrets exist only server-side and are never exposed to the browser.
Private keys
WebAuthn private keys stay on the authenticator.
Secrets
No API, provider, or webhook secret reaches the browser.
Limits
Usage quotas and rate limits reject rather than silently exceed.