How to Restrict a SaaS Feedback Widget to Your Website

You can restrict a feedback widget to its intended website by checking the website origin when the widget requests its configuration and when it submits feedback. The embed code can still contain a public site key: that key identifies the widget, while the origin check helps decide whether the request is coming from an approved website. Neither the key nor an origin check should be treated as a complete defence against abuse.

This distinction matters if you build a SaaS product with a browser-based feedback widget. Anything included in a page’s JavaScript can be inspected by its visitors, so an embed key should not be designed as a password. Instead, configure the widget for the site where it is meant to run, and validate that site during the server-side requests.

What the allowed website setting does

An allowed website setting ties a widget to the website where you intend to use it. For example, if your SaaS app is served at https://app.example.com, enter that address as the allowed website when you create the widget. Then install the generated code on that app. The key in the code identifies which widget to load; the server should still check the request against the website configured for that widget.

In Feedback Bubble, set this when creating a widget at Dashboard > Bubbles > New bubble. Enter an internal bubble name, the full website address where it will appear, and an accent colour. The allowed website is a restriction, not merely a label. Feedback Bubble’s published setup guidance says the approved website is checked when the widget loads and that mismatched origins can prevent it from appearing. See the widget troubleshooting guide.

Why the site key should not be a secret

A browser must receive the embed code to load the widget. That means a visitor can view the site key in the page’s source or network activity. Treat it as a public identifier, not a credential. Access decisions belong on the server, where the widget can be checked against the configured website, its active status, and the relevant account or submission rules.

This keeps the installation simple without pretending the key is hidden. If someone copies the code, the intended safeguard is that requests from an unapproved website are rejected. The public key alone should not be enough to authorise feedback submissions.

Check matching rules before you rely on them

The word “origin” has precise technical meaning, but implementations can differ in how they compare and store an allowed website. Before publishing a security claim or relying on the setting, ask the product team to confirm the current implementation’s rules for cases such as:

• A site with and without www, such as www.example.com and example.com.

• Subdomains, such as app.example.com versus docs.example.com.

• HTTP versus HTTPS, non-standard ports, and staging or local-development addresses.

• Whether a pasted website address may include a path or trailing slash, and how the system handles it.

Test the exact production address your visitors use, not only a development or preview site. If you serve your product from more than one hostname, confirm whether each needs its own widget configuration or a separate approved entry. The precise answers depend on the implementation, so avoid assuming that similar-looking addresses are treated as equivalent.

Origin validation is one layer, not the whole security plan

An origin check helps limit normal browser use to approved sites, but it does not establish that every request is trustworthy or stop every kind of abuse. Do not rely on it alone for rate limits, input validation, spam controls, or decisions about what data a submission may contain. Keep those protections in the request-handling system too.

Also be clear with visitors about the information collected. Feedback Bubble submissions include page details and available device and browser context, which can help you understand where feedback came from. That context does not replace a useful message, and it is separate from deciding whether a request comes from an approved website.

A practical setup check

1. Enter the intended production website in the widget’s allowed website field.

2. Install that widget’s generated code on the intended site. Treat its site key as public.

3. Test the widget on the approved site and on a different origin you control. Confirm the widget configuration and submission requests behave as expected.

4. Repeat the check for any www, subdomain, staging, or port variations your team uses, based on the product’s confirmed matching rules.

5. Before publishing the security explanation, have the product team verify the live implementation and add a current screenshot of the allowed website setting. No suitable setting screenshot is available in the supplied media for this draft.

A public embed key and a restricted website are compatible: the key identifies the widget, while server-side checks enforce where it is intended to run. Confirm the exact matching behaviour against the implementation, then document and test the domains your product actually uses.