Widget security model
What the API key does, what it doesn't, and how the widget stays inside the trust boundary.
- Last reviewed
Widget security model
The widget is designed for browser use. Some pieces are intentionally public and some are not.
What the API key does
The API key identifies which app the request belongs to. It scopes all widget traffic — surveys, responses, identity calls — to your app.
The API key is not a secret. It's meant to be visible in your frontend code, just like a Google Analytics tracking ID.
What someone can do with your API key
- See published surveys that are configured to display on your app.
- Submit responses to those surveys.
What they can't do
- Access other apps or other organizations.
- Read responses, user data, or analytics.
- Modify surveys, targeting rules, or settings.
- Impersonate identified users (that requires user authentication).
The API key is a public identifier, not an access token. All read and write access to your data goes through the getuserfeedback.com dashboard, which has its own authentication.
What controls trust
Trust comes from the app's configuration and the signals you send:
- User authentication — when enabled, the widget only works for users who carry a valid signed token from your app. This prevents anyone from using your API key to submit responses without being authenticated.
- User identity via
identify()— ties responses to known users. - Consent — controls which non-essential data scopes are active.
- App scoping — all requests are scoped to one app key. Cross-app access is not possible.
Consistent across SDKs
The JavaScript SDK, React SDK, and Google Tag Manager all share the same security model:
- Identify the user if needed
- Configure auth if needed
- Open the survey
- Reset state on logout
Switching between SDKs doesn't require a different security setup.