Security & Trust

Sefro provides U.S. sales-tax rate and calculation data over an API. We hold very little personal data — no payment cards, and only what a customer sends us (addresses on lookups, and buyer name/email/EIN on exemption certificates). This page describes how we protect it and how to report a security issue.

Compliance status

Sefro is not yet SOC 2 certified. We build and operate to the SOC 2 Trust Services Criteria (security, availability, confidentiality) and can share our security documentation — this policy, our DPA, and our incident-response plan — with enterprise customers under NDA during procurement. A formal third-party audit is on our roadmap; we will publish the report here when it is complete.

Data protection

• API keys are never stored in the clear. Keys are kept only as SHA-256 hashes; the plaintext is shown to the customer exactly once at creation and never persisted.
• No card data touches our systems. All payment information is handled entirely by Stripe; Sefro never receives or stores card numbers.
• Encryption in transit. All traffic is served over TLS; HTTP is redirected to HTTPS and HSTS is enforced. The database uses a verified TLS connection or Railway's private network.
• Secrets management. Credentials are supplied via environment variables and are never committed to source control.
• Least access. Production data access is restricted; all administrative actions are written to an immutable audit log (admin_audit) with actor, target, and request ID.

Application & infrastructure security

• A managed WAF, edge rate-limiting, strict TLS, and automatic HTTPS sit in front of the service (Cloudflare).
• Strong response security headers — Content-Security-Policy, HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a strict referrer policy.
• Cross-origin access fails closed to the marketing origin in production; request bodies are size-capped; a per-key monthly quota plus a burst limiter protect against abuse.
• Every request carries a correlation X-Request-Id, and secrets in URLs (API keys, session IDs) are redacted before anything is logged.
• Dependency scanning runs in continuous integration on every push, alongside the automated test suite and type checks, so vulnerable dependencies and regressions are caught before deploy.
• Errors are captured to our monitoring system, and uptime and the weekly data-refresh job are actively monitored.

Subprocessors

We use a small, U.S.-based set of subprocessors. We give notice of changes and allow a reasonable objection period (see the DPA).

Subprocessor	Purpose	Location
Railway	Application hosting & managed PostgreSQL	United States
Stripe	Payment processing	United States
Cloudflare	DNS, WAF & edge network	Global (US-operated)

Incident response

We maintain a documented incident-response process — detect, contain, eradicate, recover, review — with defined severity levels. For any incident involving personal data, we notify affected customers without undue delay and within any legally required window, as described in our DPA.

Reporting a vulnerability

Email [email protected] with a description of the issue and its impact, steps to reproduce, and the affected endpoint(s). Please do not open a public issue, and do not run automated scanners against production beyond what is needed to demonstrate a finding. We aim to acknowledge reports within 2 business days and to provide a remediation timeline after triage. We are glad to credit reporters once a fix has shipped.

← Back to Sefro