If a Databutton-built app exposed an API key, in generated code, a client bundle, or a shared project, treat it as compromised. Rotate the key first, then move it into Databutton's secret storage and make sure it is only used server-side. The platform managing your backend does not mean a leaked key is safe.
Why it's a problem
A key in generated client code can be extracted from the browser, and a key in a shared or public project is readable by anyone with access. Any key that touches money or data is a live liability until it is rotated, regardless of how much of the stack the platform manages for you.
How to fix it, in order
- 1Rotate the key. Revoke and regenerate it at the provider before anything else.
- 2Move it to Databutton's secret storage. Use the platform's environment or secret configuration rather than inline values, so the key is not in the client bundle.
- 3Keep the key server-side. Make the API call from server code so the key never ships to the browser.
- 4Check for unauthorized use. Review the provider's logs and billing for activity you did not create.
Why Databutton does this
Databutton generates a full app from a prompt, and when an integration needs a key the fastest working version places it where the generated code can reach it. Because the platform hides so much of the backend, an exposed key is easy to miss.
Stop it happening again
Store every key in Databutton's secret configuration, call third-party APIs from the server, and scan the app for inline secrets before you share or launch it.
The quick fix
- Rotate the key first.
- Move it into Databutton's secret storage, not inline in generated code.
- Keep the key server-side so it never reaches the browser.
- Check provider logs for unauthorized use.