Every claim on this page maps to a specific subsystem. We do not advertise a roadmap as a feature, and we do not advertise an attestation we have not yet received.
Last updated:
Pillars
Each is a real subsystem you can inspect through the API or via the audit log.
All persisted secrets — IMAP credentials, webhook signing secrets, app-level configuration — are encrypted with AES-256-GCM under a master key supplied via env. Per-row IVs prevent ciphertext correlation. Online rotation supported with PRICING_MASTER_KEY_PREVIOUS overlap window.
Email/password (bcrypt cost 12 with reuse-window) plus Google, Microsoft, and Apple Sign-In. Sessions are opaque, server-side, with idle and absolute TTLs. Brute-force lockout via sliding window. Capability catalog: 12 operational + 7 provider capabilities, published at /v1/capabilities. JWT carries org_roles claim.
Append-only common_audit_log with SHA-256 hash chaining and actingAsOrgId on every row for clean delegation evidence. previous_hash → entry_hash links rows. Verify endpoint reports first break by row id. Used as evidence in regulatory and customer audits.
PiiRedactor scrubs emails, phones, SSN-shaped numbers, and PANs from every outbound log and audit payload before persistence — including OpenTelemetry spans. Redaction is pre-write, not post-process.
SafeUrlValidator blocks loopback, private, link-local, and cloud-metadata IPs. Per-service host allowlists for outbound integrations (scrape, webhook target, IMAP). Any operator-supplied URL is validated constant-time.
TLS 1.2+ required on all external endpoints. Let's Encrypt HTTP-01 issuance via cert-manager for white-label hosts (migrated 2026-05). Internal service-to-service traffic optionally requires X-Internal-Token (constant-time verified). Private subnets for data services. Logs ship to a separate retention boundary.
Postfix/Dovecot/Rspamd transactional mail stack with DKIM/SPF/DMARC, mandatory TLS on submission, and SAFE-DEFAULT relay rules. Outbound branded email links route to the per-tenant white-label host.
Day-to-day security at RateStack is a function of platform design, not heroics. The short version: persistent secrets are ciphertext, identity is opaque-session based, every state change is hash-chained, and every outbound integration is behind an SSRF-validated URL fetch.
Persisted secrets are encrypted with AES-256-GCM via SecretEncryptor. Master keys are supplied via the PRICING_MASTER_KEY environment variable; we never persist the key itself. Online rotation requires both the old and new key to be present during the migration window — the encryptor reads with the previous key and writes with the current — and rekey endpoints re-encrypt rows in place. Once every row uses the new key, the previous key is dropped on the next service roll.
In transit, every external endpoint is TLS 1.2+. Internal service-to-service traffic optionally carries the X-Internal-Token header verified constant-time. Production environments require the token; development environments treat it as advisory.
Email/password authentication uses bcrypt at cost 12 with a sliding reuse-window check that prevents recently-used passwords from being reused. SSO covers Google, Microsoft, and Apple — Apple's client_secret JWT is signed at runtime from an operator-supplied P-256 key (we never persist Apple's secret).
Session tokens are opaque random IDs (32 bytes, base64url-encoded). The browser receives them via an HttpOnly cookie; the server-side session store maps them to user identity, permissions, and the upstream auth token. We do not issue JWTs to browsers — the public-portal BFF pattern means client JavaScript never sees an access token.
Every authenticated call is checked against the capability catalog before it reaches business logic. The catalog ships 12 operational capabilities (loan.read, loan.write,loan.share, loan.price, ratesheet.activate,lock.commit, etc.) plus 7 provider capabilities for integration partners. The catalog is published at /v1/capabilities so partners can author scoped clients without reverse-engineering.
JWTs carry an org_roles claim listing the operator's roles and any active TTL delegation grants. Roles are admin-managed; the platform role SUPER_ADMIN is the only role that cannot be self-assigned. Org admins can shrink their org's capability set; they cannot expand it beyond what their org type (ORIGINATOR / INVESTOR / CORRESPONDENT / SUBSERVICER) permits.
Cross-tenant operations record actingAsOrgId on every audit row, so a wholesale lender can prove which originator instigated each request under whose delegation grant. Administrative tools that operate against another tenant set the X-Owner-Override header. Every override writes an audit row with action OWNER_OVERRIDE, the operator's key id, the target owner, and the request URI. Operators cannot disable the audit row.
common_audit_log is append-only. Each row carriesprevious_hash, entry_hash, and acting_as_org_id; entry_hash = SHA-256(previous_hash || canonical(row)) where canonical(row) is a deterministic JSON serialization that includes acting_as_org_id. Mutating a row breaks the chain at the next row. The verify endpoint /v1/admin/audit/verify walks the chain and reports the first break (or ok: true if the chain is intact). When a delegation grant is involved, acting_as_org_id equals the grantor org id while actor.org_id equals the grantee — wholesale and TPO audit evidence is unambiguous.
AI assistant prompts and replies write to their own audit-chained log with operator id, scope, tokens consumed, and citation correlationIds. The same verify endpoint covers the AI log; an unresolved citation produces an audit warning rather than a silent pass.
PiiRedactor is a pre-write filter that scrubs emails, phone numbers, SSN-shaped sequences, and credit-card-shaped sequences from log and audit payloads. Redaction runs before persistence; we do not rely on post-process redaction in downstream log storage.
SafeUrlValidator blocks DNS-resolved IPs in the loopback, private (10/8, 172.16/12, 192.168/16), link-local (169.254/16), and cloud-metadata (169.254.169.254) ranges. Per-service host allowlists further restrict outbound endpoints — the scraper-service, webhook-service, and email-service each maintain their own. Out-of-allowlist hosts are rejected with a structured error.
API key brute-force lockout uses bucket4j on Redis: one bucket per key, consumed on every authentication failure, refilled on success. Lockout decisions are global across api-service replicas; an attacker cannot evade the lockout by hitting different replicas.
Our incident response process follows a documented playbook. Severity-1 incidents (data exposure, auth bypass, full outage) are paged to on-call within minutes; severity-2 (degraded service, partial outage) within an hour. Customer notification commitments are codified in the Business and Enterprise tier SLAs.
Vulnerability reports go to security@ratestack.com. We acknowledge within 1 business day and update reporters at least weekly until resolution. Disclosed researchers are credited in the changelog when they consent.
We work with reporters on disclosure timing. Default windows are 90 days for high-severity issues and 30 days for critical issues actively exploitable in the wild. We do not threaten reporters; we never have.
Frequently asked
We are operating to SOC 2 Type II controls today and are pursuing the audit. We do not advertise an attestation we have not yet received. The same holds for ISO 27001. Customers under NDA can review our control evidence on request.
United States by default — Tier-1 cloud regions in us-east and us-west. Enterprise customers can request a single-region pinning, dedicated infrastructure, or VPC peering.
Responsibly. Email security@ratestack.com. We acknowledge within 1 business day, triage within 5 business days, and credit disclosers in our changelog when they consent.
Yes. Common frameworks (CAIQ, SIG, vendor-specific) are answered in a maintained document; sales will share under NDA.
Production access is RBAC-gated through the same catalog used for customer admin. Every production action writes an audit row. Administrative override of customer ownership (X-Owner-Override) is logged with the operator's key id and the target.