Setu Recipes: reusable workflows across every app.Browse templates
Setuसेतु
Documentation menu

How Setu protects tokens

Setu holds access tokens for other people's accounts, so this page lists what is done, where, and what is not done yet.

Storage#

  • Each token is encrypted with AES-256-GCM under its own random data key.
  • The data key is wrapped by a master key from a pluggable key provider, which can be backed by a cloud KMS.
  • Ciphertext is bound to its connection and kind (connectionId|kind). Copying a ciphertext onto another row makes decryption fail.
  • Rotating the master key re-wraps data keys without asking users to reconnect.
  • Tokens are decrypted in memory for one call and never written to logs, errors or the execution record.

Sign-in flow#

  • OAuth state values are random, single-use, stored as a hash, and expire after 10 minutes.
  • PKCE (S256) is used wherever the provider supports it.
  • Your redirect_url must be on the project's allow-list, so the callback cannot be used as an open redirect.
  • Provider error bodies are not echoed back to callers.

Outbound requests#

  • An integration may only call the HTTPS host it declares.
  • Hostnames are resolved and rejected if they point to private, loopback or link-local addresses, which blocks DNS rebinding and server-side request forgery.
  • Path and body templates insert values as data; they cannot add path segments or pollute object prototypes.
  • Responses are size-capped and requests time out.

Tenancy and access#

  • API keys are stored as SHA-256 hashes; the full key is shown once.
  • Every database query takes the project id, and cross-tenant reads are covered by tests.
  • Per-key rate limits and monthly quotas protect shared OAuth apps from abuse.

Known limits (pre-1.0)#

  • There has been no third-party security audit.
  • PKCE verifiers sit in the state table as short-lived plaintext (10-minute TTL, deleted on use).
  • The token-refresh lock and the rate limiter are per process, so a multi-instance deployment may refresh a token twice.

Report a vulnerability to [email protected]. We acknowledge within 3 business days and coordinate disclosure within 90 days. Include the steps to reproduce and any request ids.