>
    Strata Copilot
    Browser Extension Security - Best Practices
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Browser
    3. Prisma Access Browser Administration
    4. Manage Prisma Browser Extensions
    5. Browser Extension Security - Best Practices
    Download PDF
    Prisma Browser

    Browser Extension Security - Best Practices

    Table of Contents

    Browser Extension Security - Best Practices

    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.
    1. 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.
    2. 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).
    3. Stage 1 - Identity and Risk
      Rules are processed from the bottom up (lowest priority to highest priority)
      1. The "Set Subtraction" Logic
        When specific lists conflict, they modify the set of allowed extensions through mathematical subtraction:
        Starting RuleHigher Priority RuleResulting LogicReal-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.
      2. 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 MechanismReal-Life Example
          The Filter RuleBlock 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 HatchA 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.
    4. 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" StrategyForce 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 GateForce 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" RuleBlock 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 RiskForce InstallThe 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:
      StrategyRule Preference Functional ImpactReal-Life Example
      Block First StrategyAllow List winsExtensions 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 StrategyBlock by Permission winsBlock 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.
    5. Summary Precedence Matrix
      Policy A (Lower Priority)Policy B (Higher Priority)ResultLogic
      Block AllAllow ListAllow ListStandard Exception Handling
      Allow AllBlock By RiskRisk FilteredBlock by Risk restricts the permissive Allow All baseline.
      Block By RiskAllow riskAllow List winsAllow List "rescues" an extension from a risk block.
      Force InstallBlock ListRemovedDeviation: Specific block removes forced install.
      Block by PermissionForce InstallInstalledForce Install is the highest authority over Permission blocks.
      Block by PermissionAllow ListVariesAllow List wins in Block-First; Block by Permission wins in Allow-First.
      Block By RiskForce InstallForce Install WinsAn operational mandate to install an extension ignores automated risk filters.

    Frequently Asked Questions

    1. 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. 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. 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.
    4. 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.
    5. 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.
    6. 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.
    7. 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.

    © 2026 Palo Alto Networks, Inc. All rights reserved.