Security
HyperProxy exists so that provider API keys never ship inside an app. This page describes how the managed gateway protects them, how it verifies that requests come from your real app, and what it does — and does not — keep.
Provider keys: split-key envelopes
When you add a provider key, the gateway generates a random data key, encrypts the provider key with it, and splits the data key into two halves. One half is stored server-side, encrypted again with a key that only the running service holds. The other half is embedded in the app key you ship. Neither half is stored anywhere in a form that can be reversed on its own: a copy of the database yields ciphertext plus one half; a copy of your app yields the other half and no ciphertext. The provider key exists in plaintext only in the gateway's memory, for the milliseconds it takes to forward one request, and is discarded afterwards.
Because of this design the dashboard cannot display, edit, or recover a provider key. Rotation mints a replacement app key and lets the old one keep working for a grace period you choose, so app versions already in users' hands are not cut off.
Proving the request comes from your app
An app key identifies a service; it is not an authorization boundary on its own. Each service can require device attestation before a request is forwarded:
- Apple App Attest — per-request assertions or short-lived device tokens signed by the Secure Enclave of genuine Apple hardware, with one-time challenges and counter checks against replay.
- Apple DeviceCheck — device tokens validated with Apple, with replay protection.
- Firebase App Check — for apps that already use Firebase, including Android.
Endpoint allowlists restrict every service to the upstream paths you intend to call, and per-key, per-IP, and per-device rate limits bound what a single client can do. Monthly plan allowances and optional hard spend budgets cap the blast radius of a leaked key in money terms.
What the gateway keeps
- Request metadata: timestamps, provider, model, status, latency, token counts, metered cost, and the optional client and session identifiers your app sends.
- Configuration: projects, services, allowlists, limits, prompt templates.
- Account data: email, display name, sign-in methods, and Paddle billing references.
What it does not keep
- Prompt or completion bodies. Request and response payloads are streamed through and are not written to logs or storage.
- Provider keys in a recoverable form (see above).
- Card or wallet details — Paddle, the merchant of record, handles checkout.
Request history is retained per project for a retention window you control, and every account can export its data or delete itself from Account → Security.
Platform safeguards
- TLS everywhere; the SDK additionally supports certificate pinning and rejects redirects on credential-bearing transport.
- Dashboard sign-in with passkeys, Google, or email and password; sessions are stored as hashes with CSRF double-submit tokens; Cloudflare Turnstile protects sign-up and sign-in.
- Secrets are redacted from application logs and from error monitoring; monitoring never receives request bodies, headers, or cookies.
- Dependencies are audited and the repository is scanned for committed secrets on every change; migrations are round-trip tested before deploy.
- Hosting on Railway (US West) with health-checked replicas; Paddle webhooks are verified by signature, timestamp, and source IP.
Reporting a vulnerability
Email [email protected] with steps to reproduce. Please do not post keys, customer data, or exploit details publicly, and give us a reasonable window to fix the issue before disclosure. We acknowledge reports within two business days. A machine-readable contact is published at /.well-known/security.txt.
Related
Subprocessors · Data Processing Addendum · Privacy · App Attest docs