Safari extension stability exposes browser-specific password manager limits

At a glance

What this is: This is a product story about why Passbolt’s Safari extension took years to stabilise, and the key finding is that browser-specific platform limits can break a password manager’s identity and storage model.

Why it matters: It matters because IAM, NHI, and human identity teams often assume browser support is a packaging problem, when it can actually reshape authentication flows, storage boundaries, and release risk.

👉 Read Passbolt's account of how Safari extension support finally became stable

Context

Safari browser extension support is not just a compatibility checkbox. In identity tools, the browser can control what data is stored, when sessions persist, how cookies are handled, and whether a secure workflow can actually run inside the constraints of the platform.

Passbolt’s experience shows how quickly an apparently simple browser integration turns into an identity governance problem. When extension behaviour depends on sandbox rules, iframe storage, and hidden platform exceptions, teams are no longer managing a generic app feature. They are managing the trust boundary between user identity, secrets handling, and browser execution.

Key questions

Q: How should security teams handle browser-specific failures in password manager extensions?

A: Treat them as architecture issues, not cosmetic bugs. If a browser changes storage behaviour, cookie handling, or extension lifecycle rules, the identity workflow itself can fail. Teams should isolate the affected control, define fallback paths, and verify that authentication, synchronisation, and secret retrieval still work under the browser’s real constraints.

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. A password manager or identity extension may depend on features that work in Chromium but behave differently in Safari, especially when iframes, sandboxing, or native bridges are involved. The result is not just UI inconsistency, but broken control flow.

Q: What do teams get wrong about secure browser isolation for identity apps?

A: They assume isolation automatically preserves function. In practice, the same iframe or sandbox that improves security can disrupt state propagation, event signalling, and session handling. Teams need to test whether the secure boundary still allows the application to observe and refresh identity state correctly.

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.

Technical breakdown

Why Safari extension sandboxing breaks password manager flows

Safari applies tighter extension controls than Chromium-based browsers in several areas that matter to password managers, including file downloads, clipboard use, tab handling, and data storage. If a browser extension assumes it can read, write, and synchronise state the same way across browsers, that assumption fails quickly. Passbolt’s issue was not a single bug but a chain of platform differences that forced feature removal, rewrites, and alternate execution paths. In identity tools, browser support is therefore an architectural constraint, not a front-end polish issue.

Practical implication: test identity-critical browser extensions against the browser’s actual sandbox and permission model before release.

How iframe storage and local state can silently break synchronisation

The article highlights a subtle Safari behaviour: local storage events and related change signalling do not behave the same way when the app runs inside iframes. Passbolt used iframes to isolate the password manager UI from the page it interacts with, which is a sensible security pattern. But that isolation changed how storage updates propagated, so the interface could not reliably refresh its own state. The result was not a visible crash, but a broken synchronisation model where data changed without the UI knowing. That is a classic identity integrity failure mode.

Practical implication: verify that storage events, state refresh, and UI synchronisation still work when the secure interface is embedded or sandboxed.

Why cookie filtering and native bridges changed the trust boundary

Safari’s cookie handling stripped session cookies that Passbolt expected to send, which meant requests could leave the browser unauthenticated. The workaround was to route operations through the native macOS application that sits alongside the extension, effectively moving part of the trust boundary outside Safari’s sandbox. That solved the immediate problem, but it also changed the security and operational model, because browser-native assumptions no longer held. For identity teams, this is the point where browser integration stops being purely browser-based and becomes a hybrid trust architecture.

Practical implication: map every browser-to-native hop as part of the identity trust boundary, especially where sessions or cookies are involved.

NHI Mgmt Group analysis

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.

Browser isolation can create hidden state failures even when the security design is sound. Passbolt used iframes to isolate the interface from the page, which is the right security instinct, but Safari’s storage behaviour undermined the sync model. Browser-embedded identity state drift: a secure boundary can break operational visibility when the platform does not propagate state changes consistently. The implication is that secure architecture and reliable identity operations are not the same thing.

Hybrid browser-native execution expands the trust boundary in ways many teams do not model explicitly. Once Passbolt delegated downloads and cookie-sensitive requests to the native macOS app, the extension was no longer a self-contained browser component. That matters for IAM and NHI governance because identity flows now cross execution contexts, each with different controls and failure modes. Practitioners should review whether their browser-based identity tools still behave as browser-only systems after platform workarounds are introduced.

Platform lag should be treated as release risk in identity products, not just a user experience inconvenience. Safari’s delayed feature pace and weak debugging feedback forced repeated rebuilds and migration detours. For identity teams, this means browser support decisions should be tied to supportability, observability, and rollback planning. If a browser cannot provide stable diagnostics, it can become the constraint that governs the entire control lifecycle.

Identity tooling needs a release model that tolerates partial browser parity. The article makes clear that feature parity across browsers was not realistic, and maintaining one path for Safari had downstream effects on other browsers too. That is the same shape as many NHI governance problems: one exception state can contaminate the broader control model. Practitioners should separate core identity functions from browser-specific adaptations wherever possible.

From our research:

• 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.
• Passbolt’s Safari experience reinforces that browser-specific identity behaviour can stretch remediation far beyond the point where teams think the issue is already contained, and the NIST Cybersecurity Framework 2.0 remains a useful reference for govern and protect alignment.

What this signals

Browser support will keep behaving like an identity governance issue, not a front-end decision. As more security-sensitive workflows move into extensions and embedded experiences, teams should expect the browser to shape the control boundary. The practical question is no longer whether the product works, but whether it still behaves predictably enough to be governed. For a broader control lens, the NIST Cybersecurity Framework 2.0 remains a useful anchor.

State drift is the hidden failure mode in secure browser tooling. When identity state depends on storage propagation, iframe isolation, or native handoffs, small platform changes can break the control without immediately breaking the interface. That makes observability and rollback capability as important as feature support, especially for password managers and other tools that mediate access.

Browser-mediated identity flows need release criteria that include diagnostics, not just functionality. A tool that cannot explain why it failed in production is already harder to govern. For teams running NHI or human access tooling through browser extensions, the governance bar should include reproducible telemetry, clear fallback behaviour, and explicit trust-boundary documentation.

For practitioners

• 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.
• Build release plans around browser observability Require meaningful console and network visibility before committing identity tooling to a browser-specific release path, because poor diagnostics turn simple defects into long-lived operational risk.

Key takeaways

• Safari did not just delay a browser extension release, it exposed how identity tools can fail when platform rules change the control model underneath them.
• The hardest problems were not feature gaps alone, but hidden state, cookie handling, and sandbox behaviour that broke synchronisation and session trust.
• Teams shipping browser-based identity controls should treat browser quirks, native bridges, and observability gaps as governance risks, not implementation details.

Key terms

• Browser Trust Boundary: The browser trust boundary is the point where identity or secret handling stops being fully controlled by the application and starts depending on the browser's rules. In practice, it determines how storage, cookies, extension permissions, and embedded content can affect the security and reliability of access workflows.
• State Synchronisation Failure: A state synchronisation failure happens when an application changes data but another component does not receive or act on the update. In browser-based identity tools, this can break password visibility, refresh flows, or session continuity even when the underlying security design is otherwise sound.
• Native Bridge: A native bridge is a communication path between a browser extension and a local operating system application. It can restore functionality that the browser blocks, but it also creates a new trust boundary that must be governed, monitored, and tested independently from the browser component.

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

👉 Passbolt's full article covers the rebuilds, platform quirks, and review process behind the Safari extension

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.