If you discover a suspicious browser extension, the first question is not simply whether it looks dangerous. You need to establish what it was capable of accessing, which websites that access covered, and whether there is evidence it actually used that capability.
Direct answer
How do you check what a suspicious extension could access?
Start with its permissions and host access. Chrome, Edge and Firefox separate browser capabilities from the websites those capabilities can apply to. Broad site access can allow an extension to read or modify page content on matching sites, while separate permissions can expose tabs, browsing history, clipboard data, downloads or cookies.
Critical distinction
Permission is capability, not proof of theft
An extension being allowed to read data on a site does not prove that it actually read or exfiltrated every item available there. Historical access needs stronger evidence such as code analysis, network activity, endpoint telemetry or account-side indicators.
State 1
Extension installed
You know the extension existed in the browser.
State 2
Permissions identified
You know which browser capabilities and site scopes were available.
State 3
Actual impact evidenced
Code, network, endpoint or account evidence shows that the capability was exercised or that misuse occurred.
In this guide
- What permissions actually tell you
- Check host and site access
- Map permissions to data exposure
- Could it read passwords?
- Could it steal cookies or sessions?
- Tabs, history and clipboard
- Permissions granted later
- Reconstruct the exposure window
- Capability vs actual access
- What removal does and does not fix
- Watch, investigate or escalate
- FAQs
A suspicious browser extension starts with permissions, not assumptions
Browser extensions run with capabilities granted by the browser. Chrome’s own permission guidance says a warning does not automatically mean an extension is dangerous; it describes what the extension can potentially do if the permission is granted.
That means the correct first task is to inventory the extension’s capabilities. Do not jump from a warning such as “read and change your data” to the conclusion that every password, cookie or document was definitely stolen.
TPS rule: PERMISSION GRANTED ≠ DATA THEFT PROVED.
Check which websites the extension was allowed to access
Host permissions define the websites where an extension may be able to operate. Chrome lets users restrict site access to the current site, specific sites or all sites. Microsoft likewise describes host permissions as the webpages an extension may view or modify.
In Chrome, open Extensions → Manage extensions → Details and review the site-access setting. Pay attention to whether access is limited to one domain, a list of domains or all sites.
Specific-site access
The extension’s webpage capability is limited to the listed matching sites.
All-sites access
The extension may be able to operate across a much broader set of webpages, depending on its declared capabilities.
The site scope matters because a suspicious extension that could operate only on one low-value site represents a different exposure from one that had access to email, banking, cloud administration or developer portals.
Map the permission to the type of data it could expose
| Permission or capability | What it can indicate | What it does not prove by itself |
|---|---|---|
| Read/change site data | Ability to interact with content on matching webpages | That every item on every page was read or exfiltrated |
| Host permissions | Which sites the extension’s privileged access can apply to | That the extension used the permission on every matching site |
| Tabs | Access to tab information such as URLs and titles when the relevant API rules allow it | That full page contents were necessarily captured |
| Browsing history | Capability to read or manipulate browser-history information | That account credentials were stolen |
| Clipboard | Potential access to copied data when clipboard permission is granted | That every copied value was captured |
| Cookies + matching host access | Potential access to cookies for matching hosts through the browser’s cookie API | That a specific session cookie was copied or replayed |
| Downloads | Capability related to browser downloads | That unrelated local files were automatically exposed |
Could a suspicious extension read passwords you typed into websites?
If an extension has permission to run content scripts or otherwise interact with a webpage, information present in that page can become part of the exposure surface. That can include form interactions on matching sites, depending on how the extension is implemented.
But this does not mean broad webpage access automatically grants direct access to another extension’s private password vault or every credential stored elsewhere on the computer.
Important boundary: exposure to information inside a webpage is different from direct access to another application’s protected storage.
If you typed credentials into sensitive sites while a known-malicious extension had relevant site access, treat those credentials as potentially exposed and investigate the affected accounts.
Could the extension steal cookies or authenticated sessions?
Cookie access deserves its own check. Chrome’s cookies API requires the cookies permission and relevant host permissions for the sites involved. Mozilla similarly documents host permissions as part of privileged access to host data such as cookies.
If a suspicious extension had both cookie capability and matching access to a sensitive service, session exposure becomes a more credible concern. That still does not prove a cookie was actually stolen, but it raises the recovery priority.
If authenticated session material may have been copied, use ThePulseSignal’s stolen-session-token recovery guide to separate password rotation from session revocation. Removing the extension does not automatically invalidate a session token that was already copied elsewhere.
Tabs, browsing history and clipboard are separate exposure paths
Do not treat every extension permission as the same thing. Chrome documents separate capabilities for tabs, history, bookmarks, clipboard access, downloads and other browser APIs.
Tabs
Can expose browsing context such as URLs and titles when the relevant permission is available.
History
Can expose stored browsing-history information.
Clipboard
Can expose copied content if clipboard-read access is granted and used.
This is why an extension-permission review should produce a map of specific capability → specific data class → specific site scope, not the vague conclusion that it “could read everything.”
An extension may gain additional permissions after installation
Chrome supports optional permissions that can be requested at runtime rather than only at installation. Mozilla’s WebExtensions model also supports optional permissions.
So the fact that you do not remember an install-time warning does not prove the extension never received additional access later. Review the extension’s current permissions and site access rather than relying only on memory.
Reconstruct when the extension could have accessed sensitive data
If the extension is confirmed or credibly suspected to be malicious, build an exposure window:
- When was the extension installed?
- Was there a later update or version change?
- Which permissions and host scopes applied during the relevant period?
- Which sensitive websites did you use while that access existed?
- Did you type passwords, handle API tokens, approve payments or use privileged portals during that period?
This chronology matters because an extension that became malicious after a later update should not automatically be treated as malicious for its entire installation history unless evidence supports that conclusion.
Use an evidence ladder: capability is not the same as historical access
| Evidence | What it establishes | What remains unresolved |
|---|---|---|
| Extension installed | The browser had the extension | Whether it was malicious or used sensitive capabilities |
| Permission declared/granted | The capability was available | Whether the capability was exercised |
| Host scope identified | Which websites were in scope | Whether data from those sites left the browser |
| Sensitive site used during exposure window | Relevant data may have been reachable | Whether it was actually captured |
| Malicious code or network behavior observed | Stronger evidence that the extension exercised malicious capability | The complete set of data affected unless logs prove it |
| Unknown sessions, account changes or misuse | Provider-side evidence of impact | The exact original theft mechanism unless independently established |
Removing the suspicious extension stops future execution, not past exposure
Remove or disable an extension when it is known malicious or no longer trusted. But do not treat removal as proof that the incident is finished.
Removal does not automatically:
- change a password already captured
- revoke a session cookie already copied
- undo data already sent elsewhere
- reverse unauthorized account changes
- prove that no sensitive information was accessed.
If the browser or device may have been collecting multiple credentials or tokens, use the TPS infostealer credential-rotation guide to determine which secrets need priority rather than rotating everything blindly.
REMOVED ≠ PREVIOUSLY EXPOSED DATA REVOKED.
Watch, investigate or escalate a suspicious browser extension
1
WATCH
The extension is not known malicious, its permissions are narrow and expected, and no sensitive host access or suspicious account activity is present. Restrict unnecessary access and continue monitoring.
2
INVESTIGATE
The extension has broad or unexplained permissions, operated on sensitive sites, received permissions later or was removed from a store for security concerns. Reconstruct the exposure window and inspect accounts.
3
ESCALATE
Malicious behavior is confirmed, cookie/session access was possible, privileged credentials were used during the exposure window, or unknown sessions and account changes appear. Remove the extension, secure the device and rotate or revoke affected access.
Verification boundary
Chrome, Edge and Mozilla documentation establish what permissions and host access can allow. They do not provide an ordinary user with a universal historical audit trail proving exactly what a specific extension read or transmitted on every prior page. Actual historical access may require source-code review, network logs, endpoint telemetry, browser enterprise logging or account-provider evidence.
Suspicious browser extension: frequently asked questions
Does “read and change all your data” mean all my passwords were stolen?
No. It describes a broad webpage-access capability on matching sites. It does not prove that every password was captured or that another application’s private vault was accessed.
Can a browser extension steal cookies?
It can have cookie-access capability when the required cookie permission and matching host access are present. Capability alone does not prove a specific cookie was copied.
If I uninstall the extension, am I safe?
Uninstalling stops that installed extension from continuing to operate, but it does not revoke passwords, sessions or data that may already have been copied.
Can an extension see my browsing history?
Extensions can request specific browsing-history or tab-related capabilities. Check the exact permissions rather than assuming all extensions receive them automatically.
Can I restrict an extension instead of removing it?
Chrome allows site access to be limited to the current site, specific sites or all sites. Restriction can be appropriate when an extension is trusted but requests broader access than you want. It is not a substitute for removal when the extension is known malicious.
How can I prove what a malicious extension actually accessed?
Permissions show capability. Historical proof may require extension-code analysis, network or endpoint telemetry, enterprise browser logs or provider-side evidence such as unknown sessions and account changes.
Bottom line
A suspicious browser extension should be investigated in layers: identify its permissions, identify the websites those permissions covered, reconstruct the exposure window, and then look for evidence that the capability was actually exercised.
Best investigation chain: extension installed → permissions identified → host scope identified → sensitive-site exposure window reconstructed → malicious behavior checked → affected accounts and sessions reviewed → credentials or sessions revoked only where the evidence supports it.
Last verified: August 22, 2026. This guide reflects current Chrome, Chrome Web Store, Microsoft Edge and Mozilla extension-permission guidance reviewed for capability, host access, runtime permissions and cookie exposure.
