The browser based password manager is, in 2026, the least secure password manager you can use. The autofill runs as the weakest link in your security stack. The dedicated managers are better. The phishing resistant managers are best of all.
Every major browser ships with a built in password manager. Chrome, Edge, Safari, Firefox, Brave, all of them. The browser based manager generates strong passwords. The browser based manager stores the credentials. The browser based manager autofills on the right page. The browser based manager syncs across devices through the browser vendor’s account system. The browser based manager is, on the surface, just as good as the dedicated alternatives.
The browser based manager is also the most attacked part of the browser’s security model. The autofill is, by design, accessible to every script that runs in the page. A malicious script, including one served by a compromised third party dependency, can trigger the autofill UI and capture the credential. The browser based manager runs as the password manager the attacker goes after first.
How the browser autofill actually works
The browser maintains a database of credentials, keyed by origin. When you visit a login page, the browser checks the origin against the database. If a credential exists, the browser offers to autofill. The offer is presented through the browser’s UI, generally a popup anchored to the username or password field. If the user clicks the popup, the browser fills the fields. If the user does not click, the browser does not fill.
The mechanism for the autofill is a script that runs in the page’s context. The script is, depending on the browser, a built in extension or a privileged script. The script reads the credential from the database, calls the form fields’ value setters, and dispatches the events the form expects. The script is, in most cases, not a content script in the malicious sense. The script is, however, running in the page’s JavaScript context, and the page can see everything the script does.
The visible-to-the-page part counts as the issue. A script in the page can observe the autofill. The script can read the form values. The script can copy the credential to a hidden field. The script can exfiltrate the credential to an attacker controlled endpoint. The autofill mechanism, in 2026, runs as the most reliable credential capture vector for scripts that run in the page.
Why it serves as the most attacked part of the page
The autofill amounts to the most attacked part of the page because the autofill is, by definition, the moment the credential enters the page. Before the autofill, the credential is in the browser’s secure database. After the autofill, the credential is a string in the page’s DOM, accessible to every script that can read the DOM. The window between the autofill and the user submitting the form stands as the window the attacker wants.
The attacker does not need a zero day. The attacker needs a script that runs in the page. The script can be a malicious script the attacker has injected through a vulnerable dependency. The script can be a malicious script served through a third party tag the legitimate site has loaded. The script can be a malicious script in a browser extension the user has installed. The script can be a malicious script in a service worker that has been registered by a previous visit. The script, in any of these cases, is in the page, sees the autofill, and can capture the credential.
The 2022 to 2025 series of autofill exfiltration attacks
The pattern has been used in real attacks. The 2022 to 2023 campaign by the group variously tracked as Scattered Spider, Octo Tempest, and Muddled Libra used the autofill capture pattern against a long list of targets, including MGM Resorts, Caesars Entertainment, and several large SaaS providers. The pattern is straightforward. The attacker compromises a third party script or a service worker on a legitimate login page. The malicious script waits for a high value user to autofill. The script captures the credential, exfiltrates to the attacker, the attacker uses the credential to log in as the user.
The 2024 attacks on Snowflake customer environments used a similar pattern, combined with credential stuffing from earlier breaches. The 2025 attacks on several large retailers used a browser extension based variant of the same pattern. The pattern is well known, well documented, and actively used.
What dedicated managers do differently
Dedicated password managers, 1Password and Bitwarden being the two best, do not autofill into the page’s DOM in the same way. The dedicated manager’s browser extension injects the credential through a content script that runs in an isolated world, with limited access to the page’s JavaScript. The credential is filled into the form field, but the page’s own scripts cannot read the filled value, because the value is not in the page’s accessible DOM. The dedicated manager is, in this respect, more secure than the browser based manager.
The dedicated manager also offers a domain matching check. The extension checks the origin of the current page against the origin the credential was saved for. If the origins do not match, the extension refuses to fill. The browser based manager does the same check, but the dedicated manager is more aggressive about it, and the dedicated manager’s UI makes the check more visible to the user.
The dedicated manager also supports passkeys, secure notes, document storage, shared vaults, and team administration features that the browser based manager does not. The feature gap is real. The security gap, in the autofill model, is also real.
What phishing resistant autofill looks like
Phishing resistant autofill is, in 2026, a feature of passkeys. A passkey is a cryptographic credential bound to a specific origin. The passkey is presented to the page through the WebAuthn API, which the browser mediates. The page does not see the passkey. The page sees an assertion that the browser has verified the credential against the origin. The user authenticates with a biometric or a hardware key, the browser signs the challenge, the origin verifies the signature, the user is logged in. No password is ever exchanged, no credential is ever in the page’s DOM, and the origin binding means a phishing site cannot reuse the credential.
The passkey model amounts to the right answer. The passkey model is also not universally deployed. Most consumer sites still use passwords. Most enterprise applications are migrating to passkeys, but the migration is slow, and many enterprise applications will not have passkey support until 2027 or 2028. The password is, in the meantime, still the dominant credential, and the password manager is still the most important security tool.
The realistic setup
- Pick a dedicated password manager. 1Password and Bitwarden are the two that have survived operational scrutiny. Use one of them.
- Disable the browser based password manager. In Chrome, go to Settings, Passwords, turn off “Offer to save passwords” and “Auto Sign in”. In Edge, same path. In Safari, the password manager is in System Settings, Passwords, disable for the browser. In Firefox, about:preferences, Privacy and Security, scroll to Logins and Passwords, uncheck “Autofill logins and passwords”.
- Use the dedicated manager’s browser extension for autofill. The extension handles the domain matching and the isolated world injection. The page cannot read the filled value.
- For sites that support passkeys, use the passkey. The passkey is more secure than the password. The dedicated manager stores the passkey alongside the password, and the browser uses the passkey when the site supports it.
- For sites that do not support passkeys, the dedicated manager fills the password. The browser based manager is not in the loop. The page cannot read the filled value through the autofill path.
- Audit your browser extensions. Every extension you have installed can read your DOM. Every extension is a potential credential capture point. The extension you trust today may not be the extension you trust in 6 months. Reduce the extension count to the minimum you need.
The hard tradeoff between convenience and security
The browser based manager is more convenient than the dedicated manager. The browser based manager is also less secure. The convenience comes from the autofill being one click in the browser UI, the syncing being built in, the cost being zero. The security comes from the dedicated manager’s isolated world injection, the aggressive domain matching, the phishing resistant features. The tradeoff is real. The right answer, in 2026, stands as the dedicated manager.
The cost of the dedicated manager serves as the subscription. 1Password is $36 a year for an individual, $60 a year for a family. Bitwarden is free for an individual, $40 a year for a family. The cost is, in either case, less than a single password reset at most companies, and a fraction of the cost of a single credential breach. The math favours the dedicated manager. The security favours the dedicated manager. The only thing that favours the browser based manager sits as the inertia of the default.
The bottom line
The browser based password manager counts as the most attacked part of your browser. The autofill stands as the credential capture vector. The dedicated manager is meaningfully more secure. The passkey sits as the right answer when the site supports it. Disable the browser based manager. Install the dedicated manager. Use the dedicated manager for autofill. Use passkeys when available. The work is one afternoon. The security improvement sits as the difference between a credential that walks out the door and a credential that stays put.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
