Browser Security Hardening Guide: Policies, Extensions and Update Controls

Most organisations manage their browsers less carefully than any other application, even though the browser now holds the session cookies, saved passwords and SaaS access that attackers want most. This guide is the hardening baseline: the managed policies, update controls, extension settings and attack surface reductions that a desktop engineering or endpoint security team should enforce on Chrome, Edge and Firefox, and how to roll them out without breaking line of business sites. It goes deeper on configuration than the Enterprise Browser and Browser Security Guide, which compares enterprise browsers, isolation and browser DLP, and should be read alongside it. Policy names are given as the vendors document them; always confirm the result on a test device at edge://policy, chrome://policy or about:policies before rollout.

Key takeaways

• Manage every browser, not just the default one. An unmanaged second browser on the same device bypasses every setting you enforce on the first, so inventory and either manage or remove Chrome, Edge and Firefox together.
• Updates are the control that everything else assumes. Keep the updater on, enforce relaunch with RelaunchNotification set to Required, and treat version pinning and rollback as short, documented exceptions.
• Default-deny extensions with one policy per browser. ExtensionSettings exists in Chrome, Edge and Firefox with the same "*" default scope, which makes a single cross-browser allowlist practical.
• Remove the attacker's easiest routes to cookies and passwords. Disable remote debugging and developer tools for most users, stop sync to personal accounts and move passwords into an enterprise password manager.
• Tier the baseline. A standard tier for everyone, a strict tier for administrators and high-risk roles, and a small, owned exception list keep the baseline enforceable rather than abandoned.

What the hardening baseline covers

A browser baseline is a set of mandatory, centrally enforced policies, not user preferences. It covers four areas: how the browser is updated, which extensions and add-ons can run, which built-in features that expose session data are switched off, and which protective features are forced on. It does not replace web filtering, endpoint detection or identity controls: it narrows what a malicious page, extension or local process can do through the browser. See the Secure Web Gateway and Web Filtering Guide for network-side controls.

The threats the baseline is designed against map cleanly to MITRE ATT&CK:

Policy channels: how settings reach each browser

Every enterprise browser reads policy from the operating system. Choose one authoritative channel per platform and avoid layering several, because conflicting sources are the most common reason a setting shows as "error" on the policy page.

• Machine scope first: set security policies at machine level (HKLM or device-scoped profiles). User-scoped policy can be overridden more easily and does not apply before sign-in to the browser.
• Mandatory, not recommended: Chrome and Edge distinguish mandatory policies from recommended ones that users can change. Security settings belong in mandatory.
• Cloud management and on-premises policy: when Chrome Enterprise Core and Group Policy both set a value, decide which wins and document it. Platform policy normally takes precedence unless you configure otherwise.
• Firefox ESR: large estates often standardise on the Extended Support Release, which receives security fixes without feature churn. Check each policy's Compatibility line in Mozilla's documentation before relying on it on ESR.

Update controls

Browsers ship security fixes every few weeks, and an update is not applied until the browser restarts. The most frequent baseline gap is not a disabled updater but a browser that downloaded the fix and has not been relaunched for weeks. CIS Safeguard 9.1 requires only fully supported browsers on the latest version; the settings below are how you meet it.

• Relaunch period: Edge's default relaunch period when RelaunchNotification is Required is seven days. For most estates one to three days is a better balance; the session is restored after the restart, so the user cost is low.
• Pinning and rollback are temporary: Google and Microsoft both describe them as short-term fixes. Microsoft warns that rollback can cause permanent browsing data loss unless sync is on and that it re-exposes users to known security issues. Record every pin with an owner and an expiry.
• Never zero the check period: Microsoft states that AutoUpdateCheckPeriodMinutes set to 0 stops all periodic update traffic, which means no security updates. The same mistake appears in Chrome when all update checks are disabled.
• Component updates: Chrome's ComponentUpdatesEnabled does not stop security-critical components such as certificate revocation lists, but disabling it still delays other fixes. Leave it on.
• Third-party patching tools: if your patch tool repackages browsers, make sure it does not also disable the built-in updater, or you inherit its lag. See the Patch Management Guide.

Attack surface reduction settings

These settings switch off features that most users do not need and that malware or an attacker with local access uses to read browser data. Values are for Chrome and Edge unless noted; Firefox equivalents follow.

Firefox equivalents: DisableDeveloperTools, BlockAboutConfig (stops users changing preferences that policy does not lock), DNSOverHTTPS with Enabled, ProviderURL, ExcludedDomains, Fallback and Locked set, and HttpsOnlyMode with values allowed, disallowed, enabled or force_enabled. Certificates with ImportEnterpriseRoots makes Firefox trust the operating system store, which is needed for TLS inspection but also means a rogue root added to the OS is trusted; control who can add roots.

DNS over HTTPS decision: if you run a protective DNS service, either turn browser DoH off so queries go to the system resolver, or set "secure" with a template pointing at your own DoH endpoint. The middle option, automatic, gives you neither control nor guaranteed encryption. Microsoft notes that when the policy is not configured on managed devices, Edge does not send DoH queries and may use the system resolver.

Extension baseline across browsers

The extension risk model, approval process and permission review are covered in the Browser Extension Security Guide. For the baseline, the useful fact is that Chrome, Edge and Firefox all support an ExtensionSettings policy with a "*" entry that applies to every extension without its own configuration; Mozilla based its policy on Chrome's. That lets one allowlist, expressed three times, govern the whole estate.

• Default scope: "*" with installation_mode blocked and a blocked_install_message pointing to the request form.
• Approved extensions: listed by ID (Firefox IDs that are UUIDs keep their curly braces) with installation_mode allowed or force_installed.
• Permissions and hosts (Chrome, Edge): blocked_permissions for sensitive APIs and runtime_blocked_hosts for the identity provider, admin consoles and finance applications.
• Developer mode: disallow loading unpacked extensions for standard users.
• Manifest changes: watch vendor announcements on extension platform changes, because a forced migration can break approved extensions and push users to request unvetted replacements.

Auto-update is a risk here as well as a fix: in the Cyberhaven Chrome extension breach, a malicious version published with a phished store credential was installed automatically on users' browsers and harvested session cookies. A pinned allowlist does not stop a hijacked update; permission blocks, runtime_blocked_hosts and fast removal do. For AI assistants delivered as extensions, see the AI Browser Extensions Security Guide.

Credentials, sync and profiles

The browser profile decides where work credentials end up. The Cisco breach of 2022 began with an employee's corporate credentials saved in the browser and synced to a personal Google account, which the attacker then took over; no Cisco system had to be breached to obtain the password.

• Sign-in: force sign-in with a corporate account (BrowserSignin set to force on Chrome and Edge) and restrict which accounts can sign in (RestrictSigninToPattern in Chrome).
• Sync: set SyncDisabled where personal accounts could be added, or allow sync only to the corporate tenant.
• Password manager: set PasswordManagerEnabled to disabled (Firefox: PasswordManagerEnabled false) when an enterprise password manager is deployed, and turn on password reuse warnings where your browser supports them.
• Private browsing: InPrivateModeAvailability or IncognitoModeAvailability set to disabled where DLP, extensions or logging must apply.
• Cookie protection: leave application-bound encryption on in Chrome and Edge on Windows. It does not stop malware running with higher privileges, which is why infostealer defence still needs endpoint controls. See the Infostealer Threat Guide and the Session Hijacking and Cookie Theft Guide.

Where identity fits: the browser is where human identity becomes a bearer token. Session cookies for the identity provider and SaaS consoles are as valuable as passwords, and API keys pasted into web consoles are non-human credentials that live in browser memory and history. Phishing-resistant authentication and token binding on the identity side are the counterpart to this baseline. See the Phishing-Resistant MFA Guide.

Choosing a tier: standard, strict and developer

One baseline for everyone either breaks developers or leaves administrators under-protected. Three tiers cover most organisations.

• Small organisations: start with one browser, Intune or Group Policy, and the standard tier. Auto-update with enforced relaunch, extension default deny and blocked remote debugging deliver most of the value with little effort.
• Large organisations: add the strict tier, a cloud management console for version and extension reporting, and a formal exception process with expiry. Consider an enterprise browser or isolation only after the baseline is enforced; see the Remote Browser Isolation Guide.
• Privileged access: admin consoles should be reached from a privileged access workstation or a dedicated, hardened profile, not the everyday browser. See the Tiered Administration and Enterprise Access Model Guide.

How to implement

1. Inventory: list every installed browser, version, channel and profile type per device from your endpoint management or software inventory. Decide which browsers are supported and remove the rest.
2. Pick the channel: one policy source per platform (Group Policy or Intune on Windows, configuration profiles on macOS, policies.json on Linux) and, for Chrome, decide whether to enrol in Chrome Enterprise Core for reporting.
3. Updates first: deploy updater policy and RelaunchNotification Required to all devices. This has the lowest compatibility risk and the highest value.
4. Audit extensions before blocking: export installed extensions for 2 to 4 weeks, build the allowlist from what is in genuine use, then apply default deny to a pilot ring of IT staff.
5. Attack surface settings in rings: pilot remote debugging off, developer tools restrictions, DoH and SmartScreen prompt override on IT, then a business pilot ring of 5 to 10 per cent, then everyone. Test line of business web applications, especially those using legacy authentication or browser plugins.
6. Strict tier: assign the strict settings to admin and high-risk groups, checking Edge's enhanced security exception lists for internal applications that break with JIT disabled.
7. Rollback: keep the previous policy version assigned to a rollback group, so reverting is a group membership change. For a broken browser release, use the target version policy for days, not weeks.
8. Measure and maintain: review new policies with each major release, re-baseline quarterly and expire exceptions.

Detection and measurement

• Version currency: report browser versions from endpoint management or the browser console and alert on any device more than one major version behind.
• Policy health: sample edge://policy and chrome://policy status, or collect policy error reports from the cloud console. A policy marked as error is not applied.
• Browser events: Chrome's reporting connector sends events such as malware transfer, password reuse and unsafe site visits to a SIEM or Google Security Operations. Collect them with endpoint telemetry. See the Endpoint Telemetry Guide.
• Endpoint signals: alert on browser processes started with remote debugging switches, on non-browser processes reading browser cookie or Login Data files, and on extensions appearing outside the allowlist.

Common failure patterns

• Updated but not restarted: the updater works, but users keep browsers open for weeks. Without RelaunchNotification set to Required, version compliance looks fine in the installer report and poor in reality.
• Hardening one browser and ignoring the other: Edge is locked down through Intune while Chrome or Firefox, installed by users, runs with defaults and personal sync.
• Personal sync left on: corporate passwords and cookies follow users onto home devices, as the Cisco 2022 breach showed.
• Pins that never expire: a target version set for one broken application remains in place a year later, freezing the browser on a vulnerable release.
• DoH on automatic: the browser resolves names through a public resolver, so protective DNS and DNS logging see nothing for those devices.
• Developer exceptions for everyone: developer tools and remote debugging are enabled broadly because one team needed them, re-opening the easiest cookie theft route.

Framework mapping

Practitioner checklist

• Inventory every browser and remove unsupported or unmanaged ones.
• Set updater policy to allow automatic updates and never set the check period to 0.
• Set RelaunchNotification to Required with a period of 1 to 3 days.
• Record every version pin or rollback with an owner and an expiry date.
• Apply ExtensionSettings default deny in Chrome, Edge and Firefox from one allowlist.
• Disable remote debugging and restrict developer tools outside a developer tier.
• Force corporate sign-in, block personal sync and move passwords to an enterprise manager.
• Align DNS over HTTPS with protective DNS: off or secure with your own resolver.
• Apply a strict tier with enhanced security for administrators and high-risk users.
• Report version currency, extension drift and browser security events to the SOC.

Standards and references

• Microsoft: Microsoft Edge Update policies
• Google: Manage Chrome updates (Windows)
• Mozilla: Firefox Policy Templates
• Microsoft: Browse more safely with Microsoft Edge
• Microsoft: RemoteDebuggingAllowed policy
• Google: Chrome Enterprise reporting connector
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Browser Extensions

Related NHI Mgmt Group resources: Enterprise Browser and Browser Security Guide · Browser Extension Security Guide · Windows Endpoint Hardening Guide · Mobile Device Management Security Guide