Security
Publishable keys, what not to embed, and key rotation for the Feedback SDK.
Security
Do
- Embed publishable keys (
pk_…) in client apps that use@deck-io/feedback - Store browser keys in client env vars (for example
NEXT_PUBLIC_DECK_PUBLISHABLE_KEY) - Store server-side keys in server-only env vars (for example
DECK_PUBLISHABLE_KEY) when using@deck-io/feedback/server - Use widget ids (
wgt_…) in the client — they are public identifiers - Prefer default
urlCapture="path"in the browser so query/hash secrets are not sent as metadata - On the server, pass URL / user-agent only via explicit
meta(nothing is auto-captured)
Do not
- Put secret Public API keys (
dk_…) in the browser or in this SDK - Use
NEXT_PUBLIC_*for keys that only the server should hold when you submit exclusively from Node - Treat publishable keys as “invisible” — still rotate if a key is abused
- Send full URLs (
urlCapture="full") when URLs may contain tokens
Key comparison
| Key | Prefix | Intended use | In @deck-io/feedback? |
|---|---|---|---|
| Publishable | pk_… | Widget ingest (browser or server entry) | Yes |
| Secret API | dk_… | Server Public API (themes, insights, etc.) | Never |
The server entry still uses publishable pk_… keys. It does not unlock Public API read access.
Rotation
- Go to Settings → Feedback Widget SDK
- Revoke the compromised publishable key
- Create a new
pk_…and deploy the env var update
Widgets that only had the old key will stop accepting submissions until the new key is deployed.
Scope of a publishable key
- Write-only widget feedback ingest
- Cannot call the Deck Public API
- One key can cover multiple widgets in the same organization