Handling Secrets Safely with Slater

Keep secrets off the client. Use a backend or serverless function for privileged operations and expose only scoped, time‑limited tokens to the browser.

What must never live in client code

  • Private API keys, access tokens, and credentials
  • Long‑lived tokens that grant account‑level access
  • PII or sensitive logs

Safe patterns with Slater

  • Public config only
    • Store non‑sensitive values (e.g., feature flags, public IDs) in your Slater files
  • Use a backend proxy
    • Call your server/serverless API from the browser; the server holds secrets and talks to third‑party APIs
  • Scope and rotate
    • Use restricted API keys, short TTL tokens, and per‑origin/domain restrictions
  • Fail closed
    • On errors, avoid leaking stack traces or data; show generic UI and log server‑side
  • Consent‑aware features
    • Gate tracking or data collection behind user consent when required

Example architecture

  • Browser (Slater) → your API (validates, injects scoped token) → third‑party service → response to browser

Operational checklist

  • No secrets in Slater or Webflow embeds
  • Keys restricted by domain, IP, scopes, and TTL
  • Rotate tokens regularly; revoke on leak
  • Disable minification only in staging when debugging
  • Document data flows for GDPR/CCPA reviews

FAQ

  • Is minification/obfuscation enough to hide secrets?
    • No. It reduces readability but does not protect secrets. Treat client code as fully inspectable.
  • Can I store tokens in localStorage?
    • Avoid storing sensitive tokens in localStorage. Prefer short‑lived tokens kept in memory, refreshed via secure endpoints.

Sources