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
