Resources · 19
Review browser extensions before enterprise deployment
Assess permissions, site access, updates and the ability to remove an extension.
· 12 min
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 point | What you can conclude | Evidence 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
- Describe the task
- Connect capabilities and sites
- Test boundaries
- 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.
- 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.
| Option | Declaration to inspect | Trigger and scope | Useful check |
|---|---|---|---|
| A — Selected page | activeTab + scripting; no standing host access or automatic script in this example | Explicit invocation; temporary access linked to the page’s origin | Try another origin and a restricted page; check that the extension respects the boundary. |
| B — Documentation site | scripting + host_permissions for https://docs.example.test/* | Access to the declared host; not necessarily limited to a click | Justify the need on this site and inspect background processing. |
| C — Every site | host_permissions and content_scripts.matches for <all_urls> | Very broad scope; automatic scripts according to their declarations | Ask 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.
- Task
Act on a selected page following an explicit user action.
- Permission
Examine temporary access through activeTab and the APIs needed.
- 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
| Indicator | What it measures | First action |
|---|---|---|
| Coverage | Extensions with a documented owner and purpose | Resolve ownerless installs |
| Justified access | Permissions tied to required functions | Reduce or reject excessive access |
| Changes reviewed | Material versions assessed before broad rollout | Pause a risky update |
| Removal tested | Endpoints covered by a disablement test | Fix 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
| Manifest field | What it declares | CIE review question |
|---|---|---|
| permissions | Required API permissions. | Which function justifies each capability? No warning does not mean no access. |
| optional_permissions | API permissions requestable at runtime, subject to API restrictions. | Which permissions were actually granted, and can the optional feature be removed? |
| host_permissions | Host 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_permissions | Scope within which host access can be requested at runtime. | Declared scope is not a list of sites already authorised. |
| content_scripts.matches | Patterns 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
Google Chrome · Permissions · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Hosts, paths and context: five reference points
| Declaration or mechanism | Useful interpretation | Limit 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_matches | Static-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.
Declared API permissions
| Location | Declared permission | Documentary reference |
|---|
Site declarations
| Location | Declared value | Reading aid |
|---|
Out-of-scope keys
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
- 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.
- 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.
- Repeat after change
Compare versions, permissions, hosts, rules and native components. Installation warnings depend on permission combinations; their number is not a security score.
- 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.
- Chrome Extensions — declaring permissions
- Microsoft Edge — extension management policies
- Google Chrome · Permissions
- Google Chrome · Permissions API
- Google Chrome · activeTab
- Google Chrome · Match patterns
- Google Chrome · Content scripts
- Google Chrome · Permission warning guidelines
- Google Chrome · Stay secure
- Google Developers · Site policies
