How we protect your data
Concrete, current. Updated whenever the underlying code changes.
TrackCost.ai is operated by Elevian Technologies, a privately held software company building a portfolio of cloud-native SaaS products.
Data at rest
Provider API keys (your OpenAI / Anthropic / Google / etc keys) are encrypted at rest with AES-256-GCM. The encryption key lives only in environment variables — a database dump alone is unreadable without it.
Per-user envelope encryption for stored prompts + responses on paid tiers. Each user gets a unique key derived from the master key + their user_id via HMAC-SHA256. A compromise of one user's data does not affect anyone else.
Zero Data Retention (ZDR) option on every account: prompts + response bodies are dropped at insert time. Cost / token / model metadata still flows so the dashboard works; the bodies themselves are never stored. Configurable from Settings.
PII redaction (storage-side, opt-in): regex-based masking of emails, phone numbers, US SSNs, Luhn-validated credit card numbers, and IPv4 addresses before insert. Upstream providers still receive the original payload — this is a guard against DB dumps, not a content filter.
Slack webhook URLs for the weekly digest are encrypted with the same AES-256-GCM envelope. The API never returns the plaintext URL — even to the account owner; you replace it but can't read it back.
Configurable retention: 7-day, 30-day, 90-day, 1-year, or forever per account. A nightly cleanup job purges anything past its expiry plus a hard 30-day floor on rows marked "forever" (operational guard against unbounded JSONB growth).
Data in transit
TLS everywhere. api.trackcost.ai + www.trackcost.ai are HSTS-preload-eligible.
Standard hardening headers on every response: CSP, X-Frame-Options, Referrer-Policy, X-Content-Type-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy.
CORS allowlist limited to trackcost.ai origins for the dashboard. Programmatic API access (proxy + dashboard endpoints) uses Bearer-token auth.
Outbound request safety (SSRF protection)
TrackCost lets users register custom OpenAI-compatible provider endpoints by URL — useful for self-hosted Ollama, Together AI, fly.io-hosted runners, etc. Without protection, this is a classic SSRF vector: a user could register a URL pointing at the proxy host's internal network and exfiltrate cloud metadata or probe internal services.
Every user-supplied base_url is validated at registration AND re-validated on every request (defense-in-depth):
- Must use
https://. No plain HTTP. - Must not contain credentials in the URL.
- Cannot resolve to any private / reserved address: loopback (127.0.0.1, ::1), RFC1918 (10/8, 172.16/12, 192.168/16), link-local (169.254/16 — covers cloud metadata IPs), CGNAT (100.64/10), IPv6 ULA (fc00::/7), IPv6 link-local (fe80::/10), IPv4-mapped IPv6.
- Cannot point at known cloud metadata service hostnames or
.internal/.local/localhost.
Known gap (documented): DNS rebinding. An attacker controls a hostname that resolves to a public IP at validation time and a private IP at request time. Full mitigation requires pinning the validated IP to the outbound HTTP call. On the roadmap; direct-IP and known-hostname classes are closed.
Authentication & access control
Passwords are bcrypt-hashed (cost factor 12). Plaintext passwords never touch disk or logs.
OAuth (Google + GitHub) uses the standard Authorization Code flow with a signed-JWT state nonce (CSRF defense). Refuses silent account-linking when an existing local account has a password — prevents the takeover where an attacker pre-registers a victim's email then waits for the victim to sign in with OAuth.
Session tokens are short-lived JWTs (7 days). OAuth callback no longer puts the JWT in the URL: the backend stores it under a single-use exchange code (60s Redis TTL, GETDEL-consumed), and the frontend trades the code for the token in a POST body.
API keys are 32-byte random tokens prefixed acl_ and stored only as SHA-256 hashes. The raw value is shown exactly once at creation.
Rate limiting on every auth endpoint: 5 registrations/hr per IP, 10 logins/min, 5 password resets/hr. Atomic Redis INCR + PEXPIRE NX.
Audit log for security-significant actions: privacy settings changed, OAuth registrations + logins, billing tier changes.
Architecture trade-offs (intentional)
Fail-open on Redis hiccups. Cache lookups, rate limiters, tier enforcement, and routing rules all log + continue when Redis errors. We'd rather serve a request without a side-feature than 500 the user. The proxy module's auth gate is the real abuse boundary; if it's up, you're still protected.
No request-body parsing of api_base (or any other URL field). The outbound provider URL is determined entirely by what was registered on your account — not by what arrives in a request body. This whole class of nested-body-bypass attacks doesn't apply.
Multi-instance safe job scheduling. The hourly anomaly detection, weekly digest, and nightly log cleanup all use Redis SET NX locks. Two replicas can't double-send or double-delete.
Continuous verification
An automated test suite covers the highest-risk pure code paths — encryption round-trips, payment-webhook signature verification (HMAC-SHA256, replay window, timing-safe compare), the Slack-webhook allowlist guard, the SSRF base_url validator, and the PII redaction patterns. Tests run on every push and pull request via GitHub Actions.
Error reporting via Sentry on the backend. Uptime monitored externally. Production refuses to start without REDIS_URL — multi-instance correctness is a boot prerequisite, not an afterthought.
Reporting a vulnerability
If you find a security issue, please email security@trackcost.ai with:
- A description of the issue and its impact
- Reproduction steps (curl commands, screenshots, request/response if relevant)
- Whether you'd like attribution if we publish a fix note
We commit to acknowledging within 48 hours and to a fix-and-disclosure timeline scaled to severity. We do not currently run a paid bug bounty — pre-revenue solo founder — but we name researchers in the changelog on request.
Please do not run automated scanners against production. We're solo-operated infrastructure; aggressive scanning trips uptime monitors and burns the founder's sleep. If you need to stress-test, drop a note and we'll spin up a staging environment.
On the roadmap
In progress or planned, named here for transparency:
- SSRF DNS-rebinding mitigation (IP-pinning at the HTTP adapter layer)
- Frontend Sentry (browser-side error capture)
- Public status page (uptime + incident history)
- SOC 2 Type 1 — planned once we've crossed $5k MRR; not committing to a date
Last updated when the underlying code last shipped. The implementation details on this page are pulled from the actual running code, not aspirational. Found something inaccurate? Email security@trackcost.ai.