Resources · 19

Review browser extensions before enterprise deployment

Assess permissions, site access, updates and the ability to remove an extension.

· 12 min

Fictional empty extension access review workstation, abstract permission cards and site connections on a monitor, black desk and warm gold lighting

What this guide helps achieve

  • Inventory extensions
  • Qualify permissions
  • Control updates
  • Prepare removal

Quick check

  • Which specific task requires the extension?
  • Which sites and data can it access?
  • Are permissions proportionate?
  • Who watches new versions?
  • How can it be disabled on every affected endpoint?

Step-by-step method

  1. 01

    Inventory usage

    Collect installed extensions, identifiers, versions, browsers, users, teams and owners. Find duplicates and extensions without an accountable owner.

    Deliverable: dated extension and ownership register.

  2. 02

    Define the need

    Connect each extension to a real task and available alternatives. Define the data and sites involved before judging its permissions.

    Deliverable: use and scope brief.

  3. 03

    Review access

    Read the manifest and permission warnings for host access, tabs, storage, clipboard and other requested capabilities. Distinguish standing from optional permissions.

    Deliverable: justified or reducible permissions grid.

  4. 04

    Check publisher and changes

    Document the publisher, distribution source, privacy policy and version changes. Store presence alone does not replace this review.

    Deliverable: provenance record and reassessment trigger.

  5. 05

    Deploy with controls

    Test the extension in an appropriate profile with suitable data, then set an approved list or blocking rules for the managed browser.

    Deliverable: decision, deployment settings and owner.

  6. 06

    Plan the exit

    Prepare rapid disablement, removal, identification of affected endpoints and handling of potentially exposed data during an incident.

    Deliverable: tested removal procedure.

Understand · try · decide

Read permissions through the actual task

For a Chrome Manifest V3 extension, separate the requested capability, affected sites and when access is granted. Permission count is not a security score: one broad permission can expose more pages than several limited capabilities.

A one-off action on a user-selected page can sometimes use activeTab instead of standing access to every site. This temporary permission follows an explicit gesture; it can persist across navigation within the same origin, then be revoked on a change of origin or tab closure. Restricted browser pages remain excluded.

Injecting a script through the scripting API requires the scripting permission and appropriate page access. Inspect scripts declared in content_scripts.matches too: their access cannot be reduced to the permissions list. Verify the installed version and managed browser settings, then compare observed behaviour with the agreed need.

Reference points and evidence to retain

Reference pointWhat you can concludeEvidence to retain
Capability scripting describes an injection capability without alone granting access to every site. Used API, intended function and associated page access.
Scope host_permissions and content_scripts.matches can widen affected sites. Host patterns and automatic scripts examined separately.
Trigger activeTab provides temporary access after a user invocation. Expected gesture, affected origin and behaviour after navigation.
Change A decision on one version does not cover every future change. Identifier, version, publisher, permissions and review date.

From observation to decision

  1. Describe the task
  2. Connect capabilities and sites
  3. Test boundaries
  4. Decide and review

Three scopes for one request

The .test domains are fictional. These options compare access justification rather than declare an extension safe from its manifest alone.

Justified scope
12 / 20Fictional fleet extensions with documented need, access and owner.
Review needed
6 / 20Justification or a check remains incomplete.
Removal proposed
2 / 20Abandoned use or unjustified access in this scenario.
Distribution of a fictional fleet of 20 extensions
  • 60 / 100 · Justified scope
  • 30 / 100 · Review needed
  • 10 / 100 · Removal proposed

12/20 = 60%, 6/20 = 30%, 2/20 = 10%. Categories are exclusive in this example and total 100%. They describe an internal review rather than a security rate.

Teaching comparison of Chrome permissions
OptionDeclaration to inspectTrigger and scopeUseful check
A — Selected pageactiveTab + scripting; no standing host access or automatic script in this exampleExplicit invocation; temporary access linked to the page’s originTry another origin and a restricted page; check that the extension respects the boundary.
B — Documentation sitescripting + host_permissions for https://docs.example.test/*Access to the declared host; not necessarily limited to a clickJustify the need on this site and inspect background processing.
C — Every sitehost_permissions and content_scripts.matches for <all_urls>Very broad scope; automatic scripts according to their declarationsAsk why A or B would not suffice and test sites outside the intended use.

An access declaration alone does not establish what the code does with data. These examples are not complete manifests to install.

Can access persist after navigation within the same origin?

Yes: activeTab can remain granted on the same origin. Distinguish that navigation from an origin change; temporary does not automatically mean ‘one page forever’.

Do two permissions mean twice the risk?

No. Connect capabilities, hosts, triggers, code and data. Counting permission names measures neither impact nor likelihood of misuse.

Checks before concluding

  • Connect each access grant to a necessary function and an owner.
  • Inspect hosts, automatic scripts and managed settings.
  • Test with fictional data, then review material scope changes.
  • Verify removal on affected devices and separately address data already transmitted.

Decision: choose the smallest access compatible with the verified task, document exceptions and define the events that require another review.

Change an assumption

Does a one-off task justify permanent access?

A fictional extension reformats text on the active page on demand. This need provides a baseline for reviewing its access.

  1. Task

    Act on a selected page following an explicit user action.

  2. Permission

    Examine temporary access through activeTab and the APIs needed.

  3. Gap

    Ask what justifies all-site access if the task remains one-off.

Reading exercise: the variations describe fictional situations.

Does activeTab guarantee the extension is harmless?
New evidence
Access is more limited in time, but code still runs with authorised capabilities.
What changes
Also review the publisher, function, data flows and updates. Narrower permission reduces scope; it does not certify the software.
What if it must run in the background?
New evidence
The stated need becomes continuous monitoring across several domains.
What changes
Reassess necessity, target domains and data policy. This new need must not be presented as identical to the initial one-off action.

Management indicators

IndicatorWhat it measuresFirst action
CoverageExtensions with a documented owner and purposeResolve ownerless installs
Justified accessPermissions tied to required functionsReduce or reject excessive access
Changes reviewedMaterial versions assessed before broad rolloutPause a risky update
Removal testedEndpoints covered by a disablement testFix deployment gaps and exceptions

Common pitfalls

  • Treating store listing as security approval
  • Accepting access to every site without a reason
  • Missing extensions in personal profiles
  • Failing to review permissions after updates

Frequently asked questions

Is a popular extension safe?

Popularity does not establish which permissions your use requires, which data it can access or how it may change.

Must every extension be prohibited?

A proportionate policy evaluates the need, access and managed browser context.

When should it be reassessed?

After material permission, ownership, function or version changes and during regular fleet reviews.

Extensions: permissions and access

Reading a manifest helps prepare an extension review: which APIs are requested, for which sites, and when? A declaration describes requested scope. Effective access also depends on granted permissions, browser settings, policies and executed code.

Editorial selection of 20 Chrome permissions, with names checked against official documentation on 23 October 2026. Capabilities and questions are CIE synthesis. This is neither the complete permission list nor an official risk scale; it does not automatically apply to Firefox or every Edge version.

Five declarations with different meanings

Five declarations with different meanings
Manifest fieldWhat it declaresCIE review question
permissionsRequired API permissions.Which function justifies each capability? No warning does not mean no access.
optional_permissionsAPI permissions requestable at runtime, subject to API restrictions.Which permissions were actually granted, and can the optional feature be removed?
host_permissionsHost patterns requested for capabilities that use them.Can hosts be narrowed? In this field, the path does not restrict access to a directory.
optional_host_permissionsScope within which host access can be requested at runtime.Declared scope is not a list of sites already authorised.
content_scripts.matchesPatterns for static content scripts.Also read exclusions, globs and frame options; this differs from programmatic injection.

Google Chrome · Declare permissions · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Google Chrome · Permissions API · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

20 permissions: capabilities and evidence to review

20 permissions: capabilities and evidence to review
Chrome permissionDocumented capability · CIE synthesisOperational review · CIE
activeTabTemporary access to the invoked tab after a user gesture; navigation to another origin or closing the tab revokes it.Test invocation and revocation; this is not standing access to every site.
scriptingProgrammatic JavaScript or CSS injection, with host access or activeTab as an additional requirement.Justify target pages and actions; this permission alone does not supply host scope.
tabsAccess to sensitive tab properties; most tab-management features do not require this permission.Check the need for URLs and titles; do not equate tabs with reading every page’s content.
storageExtension-specific storage with distinct areas and behaviours.Identify retained data, local/sync/session use and context access; assess secret handling separately.
cookiesCookie inspection and modification with host permissions for the relevant sites.Limit sites and test required operations; document partitioned-cookie handling where relevant.
webRequestRequest observation with host permissions; webRequestBlocking is a separate permission restricted in Manifest V3.Distinguish observation from blocking; in V3 check the policy-installed extension exception.
declarativeNetRequestDeclarative network rules; some blocking-type actions have implicit access.Review rules and actions; redirects and header modifications have their own host requirements.
declarativeNetRequestWithHostAccessThe same family of declarative rules, with host access required for every action.Compare this variant with actually granted hosts; the permission name alone does not establish access.
downloadsProgrammatic download management through the dedicated API.Justify initiation, search or manipulation and inspect actual use; this manifest reader downloads nothing.
historyBrowser-history inspection and modification through the API.Document processed URLs, recipients and business need; declaration alone does not establish actual collection.
bookmarksBookmark creation, organisation and modification.Test mutations and recovery; distinguish business backup from browser permission.
clipboardReadPermission related to clipboard reading through documented mechanisms.Check execution context and gestures required by the chosen API; review copied-data handling.
clipboardWritePermission related to clipboard writing.Observe what is replaced and when; distinguish reading from writing.
nativeMessagingCommunication with a native application registered on the endpoint.Identify the native component, installation, allowed origins, updates and removal.
debuggerDebugging-protocol transport for instrumenting supported targets.Justify the privilege and inspect commands and targets; the name proves neither authorised use nor compromise.
managementInstalled app and extension management; some operations do not require this permission.Map each operation to an API method and administrative need; not every API operation requires this permission.
identityIdentity API, including obtaining OAuth2 access tokens.Separately review OAuth client, scopes, token recipients and revocation; identity does not describe the scopes.
notificationsNotification creation using API mechanisms.Test frequency, sensitive content and interaction; permission does not establish that a notification was actually sent.
unlimitedStorageChanges to applicable storage limits; this is not a host permission.Document volume, retention and purge; do not interpret it as unrestricted access to endpoint files.
webNavigationEvents about navigation progress.Establish which navigations are tracked and transmitted; distinguish navigation events from request modification.

Google Chrome · Permissions · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Hosts, paths and context: five reference points

Hosts, paths and context: five reference points
Declaration or mechanismUseful interpretationLimit to retain
host_permissions: https://intranet.example.org/private/*A path appears in the pattern but is ignored for host permissions.Do not promise access limited to /private/ from this line alone.
content_scripts.matches + exclude_matchesStatic-script injection conditions combine inclusions and exclusions.Code may also register or inject scripts; this reader does not evaluate these conditions.
*://*.example.org/*The scheme wildcard covers HTTP and HTTPS; this pattern includes the base host and its subdomains.Do not confuse extension patterns with administrative-policy syntax.
<all_urls>Scope over allowed schemes, subject to browser-specific restrictions.The declaration does not show that every page, local file or incognito context is accessible.
activeTab and file:///*activeTab depends on invocation; file URLs require access granted in settings.Test the real context. Neither the manifest nor this reader reveals choices made in the profile.

Google Chrome · Match patterns · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Google Chrome · activeTab · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Google Chrome · Content scripts · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Local V3 manifest reader

Paste a Manifest V3 JSON manifest to inventory permissions and site declarations. Processing stays in this page: no installation, site request, local persistence, text transmission or export. Examples are fictional and illustrate result interpretation.

Limited to 64 KiB UTF-8, 200 declarations, 20 content_scripts blocks and 2,048 characters per value. The reader examines four permission lists and static scripts’ matches and exclude_matches. It retains every occurrence with its path. It does not validate pattern syntax, Chrome rules, installation warnings, globs, frames, code files, network rules, OAuth tokens, policies or granted access. Out-of-scope top-level keys are reported without reading their values; JSON accepted here can still be rejected by Chrome. For repeated JSON keys, JSON.parse retains the last value; review the original file to resolve ambiguity.

Eight examples available without JavaScript

Invoked action on a tab
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": [
        "activeTab",
        "scripting",
        "storage"
    ]
}

Three API permissions and no host lists. activeTab may supply temporary access after invocation; inspect the gesture and code. No host list does not prove no access.

Cookies and requests over broad scope
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": [
        "cookies",
        "webRequest"
    ],
    "host_permissions": [
        "<all_urls>"
    ]
}

Two API permissions and one <all_urls> declaration. Review host grants, operations and actual restrictions. webRequest is not synonymous with webRequestBlocking.

Optional capabilities
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": [
        "storage"
    ],
    "optional_permissions": [
        "history"
    ],
    "optional_host_permissions": [
        "https://*/*"
    ]
}

One required permission, one optional permission and one optional host declaration. These are possible requests, not evidence that history and every HTTPS host are already granted.

Static script with an exclusion
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "content_scripts": [
        {
            "matches": [
                "https://*.example.org/*"
            ],
            "exclude_matches": [
                "https://private.example.org/*"
            ],
            "js": [
                "content.js"
            ],
            "run_at": "document_idle"
        }
    ]
}

One matches and one exclude_matches in the same block. Both lines are displayed without automatic subtraction. js and run_at are not analysed; effective scope requires code and injection-condition review.

Permission outside the selection and misleading path
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": [
        "alarms"
    ],
    "host_permissions": [
        "https://intranet.example.org/private/*"
    ]
}

alarms is outside this 20-name selection: absence from the directory does not mean Chrome does not recognise it. /private/* in host_permissions does not limit access to that directory.

Identity and native component: visible limits
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": [
        "identity",
        "nativeMessaging"
    ],
    "background": {
        "service_worker": "worker.js"
    },
    "oauth2": {
        "client_id": "fictional.apps.example.invalid",
        "scopes": [
            "fictional-scope"
        ]
    },
    "externally_connectable": {
        "matches": [
            "https://portal.example.org/*"
        ]
    }
}

Two known permissions; background, oauth2 and externally_connectable are reported as out-of-scope top-level keys. The reader establishes nothing about scopes, service-worker code or native correspondents.

Incorrect field type
{
    "manifest_version": 3,
    "name": "CIE fictional review example",
    "version": "1.0.0",
    "permissions": "tabs"
}

permissions must be an array of strings for this reader. No partial result remains when the type is incorrect.

Manifest V2: unsupported reading
{
    "manifest_version": 2,
    "name": "CIE fictional legacy example",
    "version": "1.0.0",
    "permissions": [
        "https://*/*",
        "tabs"
    ]
}

Version 2 is explicitly refused. Its legacy host declarations are not reinterpreted as V3. No browser-compatibility verdict is produced.

Turn reading into a verifiable decision

  1. Fix the purpose and scope

    Record extension identifier, publisher, distribution source, version, browser and test endpoint. Connect each capability to a task and affected data.

  2. Compare requested, granted and observed

    Record manifest declarations, profile access choices and applied policies, then observe gestures and traffic using test data. These three levels are not interchangeable.

  3. Repeat after change

    Compare versions, permissions, hosts, rules and native components. Installation warnings depend on permission combinations; their number is not a security score.

  4. Test restriction and removal

    In managed Edge, a blocked permission can disable an extension without removing it. Check policy scope and separately remove native components and external data where required. Retain evidence of the final state.

Google Chrome · Permission warning guidelines · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23

Technical references: Google Chrome for Developers and Microsoft Learn, linked below and at each permission. Google documentation is CC BY 4.0 except where noted; descriptions and questions above are CIE editorial synthesis adapted into French and English. Fictional examples are original. This page is not a Google or Microsoft validation.

Google Developers · Site policies · Documentation attribution and reuse conditions

Creative Commons Attribution 4.0

Verified documentary source

Chrome permissions · 2026-10-23

Source HTML SHA-256: 0d8d9b108def74b5a47c392b5c9018ed0bf6b3e02a12315a95b31e7e753c5166

Official references

References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.