Focus

Browser Extension Security - Best Practices

Table of Contents

Browser Extension Security - Best Practices

Where Can I Use This?	What Do I Need?

This document provides an overview and best practices for managing browser extension policies within an organization. It establishes a framework for how security rules and operational mandates interact to determine which extensions are permitted, blocked, or force-installed.

Choose your Baseline - the Strategic Starting Point.
Before creating any rules, we recommend that you decide which organizational policy best fits your organizational needs. This choice determines hoe subsequent security filters behave.
1. Block-First Strategy (Recommended for High Security): Start with a Block All rule, then explicitly grant exceptions via an Allow List. This is the most restrictive and secure approach.
2. Allow-First Strategy (Recommended for User Flexibility): Start with an Allow All rule, then layer Block by Risk or specific Block Lists to remove dangerous items.
The Core Mental Model - Two Stage Resolution
Policies are applied in two separate and distinct stages:
1. Stage 1: Identity Resolution (The Stack): The system resolves the extension's status based on its specific ID or broad type (Allow All, Block All, Allow List, or Block List).
2. Stage 2: The Security Vetoes: Once the identity is resolved, the system applies the "Security Filters" (Block by Risk and Block by Permission) and the "Operational Mandate" (Force Install).

Stage 1 - Identity and Risk

Rules are processed from the bottom up (lowest priority to highest priority)

The "Set Subtraction" Logic

When specific lists conflict, they modify the set of allowed extensions through mathematical subtraction:

Starting Rule	Higher Priority Rule	Resulting Logic	Real-Life Example
Allow List (Set A)	Block List (Set B)	Allow List (A minus B): The Block List removes its items from the allowed set.	Scenario: You allow 3 productivity extensions (A, B, C). A new security policy blocks extension B. Result: Only A and C remain allowed.
Block List (Set B)	Allow List (Set C)	Block List (B minus C): The Allow List creates exceptions, removing its items from the blocked set.	Scenario: You block all File Sharing extensions(X, Y). Finance specifically needs App X. Result: App Y remains blocked, but App X is now an exception and allowed.

Integrating Block by-Risk

Block by Risk acts as a filter that sits on top of the Identity resolution:

The Filter Rule: If an extension is 'Allowed' by its identity in Stage 1, the system checks for any active Block by Risk rules. If the extension matches the risk level defined in the highest-priority rule, it is Blocked.

The Escape Hatch: A high-priority Allow List / Allow by ID rule is the only way to "rescue" a specific extension that has been caught by a broad Block by Risk policy.

Feature	Mechanism	Real-Life Example
The Filter Rule	Block by Risk acts as a security gate for extensions allowed by the stack.	Scenario: You have a Block-First strategy. You add a Translation App to your Allow List. (in higher priority) However, the app is later flagged as High Risk (in higher priority) because of excessive data collection. Final structure: High risk rule on top of allow list on top of block all Result: The extension is Blocked because the Risk Rule (Stage 2) overrides the Allow List (Stage 1).
The Escape Hatch	A high-priority Allow List rule can specifically "rescue" a risky extension.	Scenario: You have a broad policy to Block High Risk extensions. Your developers need a specific Debugging Tool that is flagged as High Risk due to its deep browser access. Result: You place the Debugging Tool ID on an Allow List with a higher priority than the Risk rule. The tool is Installed, effectively bypassing the broad risk block for that specific case.

Stage 2 - High-Priority Vetos

These rules sit outside the standard stack and can override the results of Stage 1.

A. Force Install: The Operational Mandate

Force Install ensures that an extension is present and enabled, regardless of the blocking rules

Force Install vs, Block All → Force Install wins.
Force Install vs Block by Permission → Force Install wins.
Force Install vs. Block by Risk → Force Install wins .

Force Install vs, Block List → Block List wins (Critical Deviation). An explicit ID-based block removes even a Force Installed extension. When the Block List rule is removed, the extension is re-installed

When Force Install Encounters...	The Winner is...	Real-Life Example
A "Block All" Strategy	Force Install	Scenario: You have a strict "Default Deny" policy that blocks all extensions. However, you Force Install the corporate password manager. Result: The password manager stays installed and working, even though everything else is blocked.
A "Block by Permission" Security Gate	Force Install	Scenario: You block all extensions that request "Access to all websites" for security. You then Force Install a security agent that needs that exact permission. Result: The security agent bypasses the gate and stays active.
A specific "Block List" Rule	Block List (The Exception)	Scenario: You Force Install a specific browser Extension. Later, you discover a bug and add that Extension ID to a Block List to stop its use. Result: The Block List rule "wins" and removes the extension. If you later delete that Block List rule, the extension will automatically re-install
Force Install meets Block by Risk	Force Install	The extension remains active regardless of its risk score.

Known Limitation: Identity-Based Blocking with Force Install

Current Behavior There is a known limitation regarding the "Kill Switch" functionality when using a Block All strategy alongside Force Install mandates. Currently, if a global Block All rule is active, a specific Block List (Identity-based block) may fail to remove an extension that is also present in a Force Install policy.

Impact: In this specific configuration, the Force Install mandate maintains the highest authority, preventing the surgical removal of a forced extension via its specific ID. Broad security filters, such as Block by Permission and Block by Risk, also remain bypassed by the Force Install mandate as intended.

Workaround: You can successfully remove or disable a Force Installed extension while this limitation exists; You need to manually remove the extension's ID from the Force Install policy list

B. Block by Permission: The Security Veto

The power of the Block by Permission rule depends on the initial strategy chosen in Section I:

Strategy	Rule Preference	Functional Impact	Real-Life Example
Block First Strategy	Allow List wins	Extensions specifically allowed via an Allow List bypass the Block by Permission check.	Scenario: You block all extensions by default. To be extra safe, you also block the "Access to all website data" permission. Your Finance team needs a specific Legacy Reporting Tool that requires that exact permission. Result: You add the tool’s ID to your Allow List. The extension installs and runs. The system assumes that because you manually vetted it in a strict environment, you trust its permissions.
Allow First Strategy	Block by Permission wins	Block by Permission acts as a final gate and disables extensions even if they are on an Allow List.	Scenario: You allow all extensions by default. To prevent data theft, you set a Block by Permission for "Access to File System". A user wants to install a Photo Editor that is on your "Approved Apps" Allow List but requires that forbidden permission. Result: The Block by Permission rule wins. The extension is disabled. The system treats the permission block as a "final safety gate" because your overall environment is permissive.

Block Permission Behavior

If a forbidden permission is Required, the extension is Disabled.

If a forbidden permission is Optional, the extension runs but the Permission is Revoked.

Summary Precedence Matrix

Policy A (Lower Priority)	Policy B (Higher Priority)	Result	Logic
Block All	Allow List	Allow List	Standard Exception Handling
Allow All	Block By Risk	Risk Filtered	Block by Risk restricts the permissive Allow All baseline.
Block By Risk	Allow risk	Allow List wins	Allow List "rescues" an extension from a risk block.
Force Install	Block List	Removed	Deviation: Specific block removes forced install.
Block by Permission	Force Install	Installed	Force Install is the highest authority over Permission blocks.
Block by Permission	Allow List	Varies	Allow List wins in Block-First; Block by Permission wins in Allow-First.
Block By Risk	Force Install	Force Install Wins	An operational mandate to install an extension ignores automated risk filters.

Frequently Asked Questions

What is the difference between "Block-First" and "Allow-First" strategies?
- Block-First (Default Deny): You start by blocking all extensions and then create specific "Allow List" exceptions. This is the most secure posture and changes how security gates (like permissions) behave.
- Allow-First (Default Permit): You allow all extensions by default and use "Block by Risk" or "Block Lists" to filter out the bad ones. This is more flexible but requires stronger automated security gates.
2. Why is my "Force Installed" extension being removed?
- The Specificity Rule: While Force Install is a high-authority mandate, an explicit Block List rule for that specific extension ID will remove it.
- Self-Healing: If you remove the ID from the Block List, the extension will automatically re-install because the Force Install mandate is still active.
3. How does "Block by Permission" actually affect the extension?
I depends on how the developer coded the application:
- Mandatory Permissions: If you block a permission the extension requires to function, the extension is Disabled.
- Optional Permissions: If you block an optional permission, the extension stays Enabled, but that specific feature is Revoked and will not work.
Can I allow an extension that is flagged as "High Risk"?
- Yes (The Escape Hatch): You can "rescue" a specific extension by adding its ID to an Allow List with a higher priority than your Block by Risk rule. This allows you to manually vet and approve a tool that the system would otherwise block.
Why did my Allow List override the Permission Block in one group but not the other?
It depends on your strategy:
- In a Block-First setup, an Allow List is treated as a manual administrative vetting and Wins over permission blocks.
- In an Allow-First setup, the Block by Permission gate is treated as a final safety net and Wins over the Allow List.
What happens if I have an Allow List and a Block List for the same IDs?
Identity Subtraction: The system uses "Set Subtraction." A higher-priority Block List will "carve out" its items from a lower-priority Allow List.
- Example: If you allow "Tools A, B, and C" but block "Tool B" at a higher priority, only A and C remain allowed.
Does Force Install bypass the "Block by Permission" gate?
Yes: An operational Force Install mandate is considered a higher authority than a security permission gate. If you force an extension, the system assumes you have already reviewed and accepted its permissions.

Advanced Extension Security

Manage Prisma Browser Policy Rules