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 can recover the provider credential on its own. A database copy contains encrypted provider credentials and an encrypted server half; your app carries the client half without that ciphertext. The provider key exists in plaintext in gateway memory while forwarding an authorized request. It is not deliberately written to logs or persistent storage in plaintext.
Because of this design the dashboard cannot display, edit, or recover a provider key. Minting or rotating a split-key app key requires you to supply the provider credential again. 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 — Secure Enclave assertions from genuine Apple hardware, with one-time challenges and counter checks against replay. After validation, HyperProxy can issue a short-lived server-signed device token; that bearer token is not a Secure Enclave signature on each request.
- 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
- Transit request and response bodies in request history or new application logs. Optional response caching keeps eligible JSON response bodies in Redis for your selected TTL, up to 7 days. Deliberately saved templates and annotations are stored separately. Legacy error excerpts may remain until retention expires, as described in the Privacy Policy.
- A complete split-key credential in persistent storage. Optional server-side service or channel key overrides use encryption at rest and can be decrypted by the running service; they have a different security boundary.
- 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
- Public connections use HTTPS; 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 configured deployment health checks; 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