Enterprise default URI detection questions

Ask the Community Password Manager
, , , ,
1

Hello,

New to Password Manager Enterprise and wasn’t sure how to phrase this in my searches prior to this post. If this has been answered, please direct me to that community post.

Is it possible to tell the browser extension not to suggest credentials from similar sites and only match a specific URL/URI?

Apologies for the [.] entries as I’m new and it will only let me post 1 link at a time.

Example: vault[.]bitward[.]com vs. community[.]bitwarden[.]com

When I go to vault.bitwarden.com and click the shield behind the E-mail Address field, it suggests the credentials for community site. How can I prevent the community vault entry from popping up if it doesn’t match the domain or sub-domain?

Again, this is just an example, and I do not store my master password in any of our vaults.

2

Hello,

Are you talking about an enterprise-wide policy or an individual preference? You may want to experiment with “Host” instead of “Exact” right away because the latter requires all URL parameters to match. For individual preferences, you need to set it per client and every time you reinstall.

1 Like
3

**EDIT** I just noticed that Admins and Owners are exempt from this policy, which all of us are in our small department.

Thank you. What I have set currently in our policy is Exact. We’ll only want to use the Enterprise policy and not individually. With that info, would you suggest we go with Host instead?

image
image543×452 25.3 KB

4

For enterprise-wide configuration, I’ll defer to other members (usually one) who have expertise.

P.S.: I edited your title and tags to match what you asked, hoping they will attract more attention.

1 Like
5

That is for you to decide. Depending on how your users use their vaults and what sites they mostly store there. You will have to answer this:

What would be the default match detection that most of our users would set in their client settings?

I, personally, don’t like to set it to:

host: it will fail for websites that, for example, use subdomains for login pages
exact: it will fail for a lot of websites.
never: for obvious reasons

So I left that policy unset so they use the default base domain option and instructed our users to change it on the items of their vaults that they need to (for example, the many web applications that we host under subdomains of our main corporate domain).

This way, If someone wishes to change their default domain match detection on their client settings, they can.

Btw, I don’t like that this setting is client specific and not synchronized between all of them.

1 Like
6

Even though I personally have set the default URI match detection method to Exact for my individual account, I would not recommend this for anybody who doesn’t deliberately make this choice for themselves based on a good understanding of the trade-offs involved.

First, the Exact setting, while being the most secure option (providing the best defense against credential theft by phishing or info-stealing scripts), is also a high-maintenance setting, requiring a significant degree of manual customization when creating new login items. For example, the account registration page, the password change page, and the login page typically have different URLs — thus, you will need to manually add at least two URLs to the login item before it will work as expected.

And since version 2025.12.0, this URL customization process has been made significantly more cumbersome, because someone at Bitwarden made the inexplicable (and completely irrational) decision to deliberately remove the “Autofill and Save” function for users who prefer Exact matching. Thus, the only way to add the required URLs is to manually copy the URL from the browser address bar, then manually edit the login item, click “Add Website”, and finally paste the URL and save the item. Repeat for the other web pages where password autofill is required.

Second, Exact matching will not work at all for some websites, if the URL for the login form is not constant. For example, the URL may include a query parameter representing some temporary token or tracking ID, and that part of the URL will change every time that you visit the login page in question. Thus, it is important to inspect each stored URL for hallmarks of variable content, then manually edit the URL string to truncate it at the start of the variable portion, and finally, customize the URI Match Detection method for that specific URL to use Starts With instead of Exact.

Third, for login forms that use an iframe to display the input fields, Bitwarden’s mismatch warning only shows the host name for the iframe source URL. Thus, one either needs to inspect the HTML source code (e.g., using DevTools) to identify the full URL for the iframe (to then manually add as an additional website for the login item), or one needs to customize the URI Match Detection method for the iframe URL to use Host instead of Exact.

Thus, using Exact as the default setting is not for the faint of heart, and I would recommend against foisting this choice on other users in your organization.

1 Like
7

Neuron, thank you for editing those tags. I didn’t see the plans-enterprise one but will use that in the future.

@kpiris I did change it to Host to see if it helps, but will experiment?

@grb Thank you for the detailed response. That’s helpful. It sounds like we should avoid Exact and if Host doesn’t work, we’ll test out the Starts with.

Due to cost, we currently have no plans to roll Password Manager out to other departments. If we’re all owners/admins, how do I enforce Host or Starts with to our 10 staff since that Enterprise policy suggests it doesn’t apply to our roles?

8

Starts With is another one to be careful with (and probably not suitable as the default option). For example, if someone stores the URL bitwarden.com and uses Starts With matching, then the credentials could be autofilled on a malicious form hosted at bitwarden.completelybogusdomain.net, etc.

Host is probably OK, but for some websites, you will have issues when the account registration page and the login authentication page are on different subdomains (in such cases, you can search for the login item, then select “Autofill” in the More Options menu, and click “Autofill and Add This Website”).

1 Like
9

Agreed. In fact, it is not available to be set with the enterprise policy:

Screenshot 2026-02-25 16.46.13
Screenshot 2026-02-25 16.46.13580×521 30 KB

10

You will not be able to enforce most policies to owners or admins of the organization. They are excluded from them by design choice (of bitwarden). To prevent situations where a wrong policy could leave every account locked out.

11

For us Admins, how do we force our web browser extensions to use Host?

12

@grb the team has been working on supporting the previous functionality to work with the new prompt in the browser extension, and should be available soon.

13

:eyes:

I’m glad something is being done, but…

  • Based on Github discussions, I feel that the Dev team might not fully understand the problem that was created — thus, I hope that the fix actually fixes the real problem.
    :crossed_fingers:

 

  • Although I recognize that I have a limited perspective on the full Bitwarden code base, it seems to me that there was a deliberate choice to deny access to the forced autofill functionality for “Exact” matchers, so it is difficult to understand not only why that choice was made, but also, why it is necessary to “work on” a solution to a problem that was unnecessarily created (i.e., why not simply roll back the change)?
14

If you just want to configure this for your own browser extension, open the extension and go to Settings > Autofill > Additional Options, where you will find a drop-down selector for “Default URI match detection”:

image
image364×331 5.73 KB

15

Thanks @grb that existing feature was reworked and launched with MVP and it will be back up to speed soon (rest assured we have additional internal discussions outside of Github).

1 Like