Notifications
Clear all
Topic starter
08/07/2026 6:57 pm
TL;DR: Browser-specific restrictions, MV3 migration pressure, iframe storage quirks, and cookie handling broke assumptions the extension architecture relied on, causing PassBolt’s Safari extension to take four years to stabilise, according to PassBolt. The result shows that browser support in identity tools is governed by platform constraints, not feature parity.
NHIMG editorial — based on content published by Passbolt: Safari: It Should Be Okay
Questions worth separating out
Q: How should security teams handle browser-specific failures in password manager extensions?
A: Treat them as architecture issues, not cosmetic bugs.
Q: Why do browser extensions for identity tools fail differently across browsers?
A: Because browsers do not implement the same permission model, lifecycle behaviour, or storage semantics.
Q: What do teams get wrong about secure browser isolation for identity apps?
A: They assume isolation automatically preserves function.
Practitioner guidance
- Map browser-specific trust boundaries Document where browser extensions rely on cookies, storage events, clipboard access, downloads, or tab control, then classify which parts stay inside the browser and which parts depend on native helpers.
- Test state synchronisation inside sandboxed contexts Validate that secure UI components still refresh correctly when they run in iframes, embedded views, or other isolated containers, because storage change signalling may not behave consistently.
- Treat native bridges as security boundaries Review any extension-to-native handoff for authentication, file writing, or session handling as a separate trust boundary, and define what data crosses it and why.
What's in the full article
Passbolt's full article covers the engineering detail this post intentionally leaves at the governance level:
- The step-by-step chronology of how Safari's extension rules forced repeated rebuilds and feature removals
- The specific debugging dead ends encountered in Safari MV3, including the limits of console and network visibility
- The local storage and iframe workaround that required a full rewrite of the extension's state-handling model
- The native macOS companion flow used for downloads and cookie-sensitive requests
👉 Read Passbolt's account of how Safari extension support finally became stable →
Safari extension stability: what it means for password manager teams?
Explore further
08/07/2026 7:20 pm
Safari support is an identity architecture problem, not a browser compatibility task. The article shows that a password manager can be technically functional in one browser and structurally broken in another because the platform changes the rules for storage, cookies, and execution timing. That is a governance issue because the identity control plane is now partly owned by the browser vendor. Practitioners should treat browser-specific execution as part of the identity system design, not an afterthought.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why operational controls drift even when policy looks strong on paper.
A question worth separating out:
Q: When should a browser extension rely on a native application companion?
A: Only when the browser cannot safely or reliably perform the required action, such as file writing or cookie-sensitive request handling. Once the native app becomes part of the flow, teams must govern it as a separate trust boundary and verify that the identity controls still behave consistently across both components.
👉 Read our full editorial: Safari extension stability exposes browser-specific password manager limits
