Salesforce Lets You Allowlist Chrome Extensions on Experience Cloud Sites

TL;DR

• Winter '27 lets you add Chrome extension URIs as trusted URLs, controlling which extensions can interact with your Experience Cloud site.
• Setup, then Trusted URLs, then New Trusted URL. The value is the 32-character extension ID, as chrome-extension://abcdefghijklmnopabcdefghijklmnop.
• Wildcards are not supported. Every extension you permit is a decision somebody makes on purpose, with the ID in hand.
• The idea behind it is bigger than the feature. A browser extension runs inside your user's session, with access to what the page can see, and most orgs have never had a control for that.
• Available in Professional, Enterprise and Unlimited editions, on Lightning Experience.

What You'll Learn

• What a browser extension can actually reach on a page your users are authenticated to
• How the extension ID format works and why it uses only the letters a to p
• Where this control sits relative to the Trusted URLs you already manage
• The practical problem of finding out which extensions your users run

The Problem

Every control an org puts around its data assumes something about the browser. Session timeouts, IP restrictions, MFA, transaction security policies: all of them are about who gets a session and under what conditions. None of them say anything about what else is running inside the browser once that session exists.

A browser extension is code with a privileged view of the pages a user visits. Depending on what it has been granted, it can read the DOM, watch network activity, and see the contents of a page that a properly authenticated user is looking at. From the platform's point of view, that traffic is indistinguishable from the user, because it is the user's session.

For an Experience Cloud site, that matters more than for internal Lightning pages, because the population is wider and less controlled. Your internal users have managed devices and a browser policy. Your community members, partners and customers have whatever they have installed.

Until this release, Salesforce offered no way to express a preference about that. Winter '27 adds one.

Common questions this article answers:

• What can a browser extension actually see on my Experience Cloud site?
• How do I find the extension ID I need to enter?
• Does this stop an extension from working, or just from talking to my site?

Quick Answer

Winter '27 lets you add Chrome extension URIs to the Trusted URLs page in Setup, controlling which extensions can interact with your Experience Cloud site. Go to Setup, find Trusted URLs, click New Trusted URL, and enter the extension in the form chrome-extension:// followed by the extension's 32-character ID, which uses only the lowercase letters a to p. Wildcards are not supported, so each extension is permitted individually and you need its ID before you can allow it. The change applies to Lightning Experience in Professional, Enterprise and Unlimited editions. It deserves attention despite being a small feature because browser extensions run inside an authenticated user's session with access to what the page can see, which is a data-exposure surface most orgs have never had any control over, and Experience Cloud sites are where you have the least influence over what your users have installed.

The extension ID, and why it looks strange

The ID is 32 characters and uses only the letters a through p. That is not a Salesforce constraint, it is how Chrome generates extension identifiers: the ID is a hex-derived value where each hex digit is mapped onto the first sixteen letters of the alphabet, so 0 becomes a, f becomes p, and no digits appear at all.

Knowing that is useful for one practical reason. If somebody hands you an extension identifier containing a digit, a capital letter, or anything past p, it is not a Chrome extension ID and it will not work here. That is a five second validation you can do before opening a ticket.

To find a real one, open chrome://extensions in Chrome, turn on Developer mode, and the ID appears under each extension. It is also the last path segment of the extension's Chrome Web Store URL, which is the easier place to get it when you are working from a name rather than a machine that has it installed.

Where this sits among your existing Trusted URLs

Trusted URLs is not a new page, and this is not a new mechanism so much as a new kind of entry in an existing one.

The page already governs which external origins content on your pages may reach, which is the same control surface that matters in supply-chain style incidents. That is worth connecting deliberately: the ForcedLeak vulnerability turned on an expired domain that was still sitting in an allowlist, where an attacker could register it and inherit the trust that entry conferred. Same page, same class of problem, different direction of travel.

The lesson transfers directly. An allowlist is only as good as its maintenance, and an entry that made sense two years ago is a liability if nobody owns reviewing it. If you add extension entries, add them to whatever review you already do for this page. If you do not review this page, that is the finding rather than the extensions.

The hard part is not the configuration

Adding a trusted URL takes a minute. Knowing which extensions to add does not.

For an internal-facing site with managed devices, your endpoint management tooling already knows what is installed and can give you a list. That is the straightforward case.

For a public or partner-facing Experience Cloud site, you do not have that visibility and cannot get it. Your members install what they like. So the realistic use of this feature on a public site is not building a complete allowlist of everything your users run, because that list does not exist and would change daily. It is permitting the specific extensions your site actually depends on, if any, such as an accessibility tool or a partner-supplied integration, and understanding that everything else falls outside.

That distinction is worth being clear about before you promise anybody an extension policy for a public community.

Frequently Asked Questions

Q: Does this stop an extension from running in the browser?

A: No, and it could not. Salesforce has no ability to control what a user installs or what runs on their machine. What this controls is whether an extension can interact with your Experience Cloud site, which is the part that is actually yours to decide.

Q: Do we need to do anything if we add nothing?

A: Adding nothing is a valid position and is what almost every org will do initially. This is an opt-in control, so leaving Trusted URLs as it is today changes nothing about how your site behaves. The reason to engage with it is if you have a specific extension you depend on, or a compliance conversation where "we have no control over browser extensions" has previously been the honest answer.

Q: What about Firefox, Safari and Edge?

A: The release note is specific to Chrome extension URIs and the chrome-extension:// scheme. Edge uses a Chromium extension model but a different scheme, and the note does not extend to it. Treat this as Chrome-only until Salesforce documents otherwise, and do not assume a control here covers your whole browser estate.

Q: Can we allow a category of extensions instead of listing them?

A: No. Wildcards are not supported, so there is no way to express "all extensions from this publisher" or any other grouping. Every entry is one extension. That is more work and it is the safer default, since a wildcard in an allowlist is how allowlists stop meaning anything.

Q: Is this a Release Update with a deadline?

A: No. It is a new capability available in Winter '27, not a change enforced on a date, so nothing breaks if you never use it. That also means nothing will remind you it exists.

Key Takeaways

• Chrome extension URIs can now be trusted URLs on an Experience Cloud site, added from Setup exactly like any other trusted URL.
• The format is chrome-extension:// plus a 32-character ID using only the letters a to p, which doubles as a quick validity check.
• No wildcards, so each extension is an explicit decision and you need the ID first.
• It controls interaction with your site, not what runs in the browser, which is the only part Salesforce could control.
• The allowlist maintenance lesson from ForcedLeak applies here too. An entry nobody reviews is a liability, whatever kind of entry it is.

What's Next?

If you run an internal-facing Experience Cloud site with managed devices, ask your endpoint team for the installed extension list. That is the one scenario where a meaningful allowlist is achievable, and doing it while the list is obtainable is the easy version.

Either way, use this as a prompt to review the Trusted URLs page you already have. Most orgs have entries on it that predate anyone currently working there, and that is the more likely finding than anything to do with extensions. The reasoning is in Salesforce Agentforce and ForcedLeak.

For the rest of the release, see Salesforce Winter '27 Security Readiness.

Resources & References

• Salesforce Winter '27 Release Notes, Security, Identity, and Privacy, Other Changes, in Salesforce Help.
• Setup, then Trusted URLs, for the page itself.
• chrome://extensions with Developer mode enabled, for finding an extension ID locally.
• Salesforce Agentforce and ForcedLeak for what an unmaintained allowlist entry can cost.
• Salesforce Winter '27 Security Readiness for the release as a whole.