Security and threat model
We assume Relaygate is a high-value target because we hold debrid credentials and mediate traffic.
Secrets
- We encrypt upstream debrid tokens at rest.
- We hash developer API secrets like passwords; we never store them reversibly.
- We never log raw proxy keys, developer secrets, or debrid tokens in application logs or queue payloads.
- We redact query parameters and headers in audit trails where they might contain tokens.
We also store provider transcripts for debugging, with strict redaction rules:
- no raw bearer tokens
- no internal shared tokens
- injected query tokens are persisted as
[REDACTED]
Authentication surfaces
| Credential | Who holds it | Purpose |
|---|---|---|
| Developer API secret + addon identifier | Addon server | Proves an approved integration. |
| User proxy API key | End user (Stremio config) | Selects vault; must be paired with valid developer auth on each call. |
| Session / 2FA | End user (browser) | Dashboard and vault management only. |
Inbound vs outbound
Inbound to Relaygate: addon developers (not “Real-Debrid as a customer”).
Outbound to debrids: Relaygate uses the user’s vault token for the selected provider.
Rate limiting and abuse
We rate-limit by client IP and by credential ids. We monitor 429/error spikes from upstreams. We may revoke developer approval or disable user keys on abuse.
IP allow/deny
The IP we see is usually the addon backend, not the viewer’s TV. We document this clearly for users. Client-supplied forwarded headers are spoofable and are not trusted.
Incident response (outline)
- Rotate compromised secrets; force developer secret rotation where needed.
- Invalidate affected user proxy keys and notify users.
- Preserve audit logs for investigation (subject to retention policy).