# Phishing protection browser add on

> Set up a phishing protection browser add on safely, review permissions, validate the control, and keep a rollback path.

A phishing protection browser add on can add a useful warning layer, but start by enabling the browser's built-in protection and treat any extension as a separately approved control. Choose one whose permissions, privacy terms, support path, and removal process your organization can accept. Then validate the configuration with an authorized, harmless exercise. This process cannot prove that a particular site is safe or that every phishing attempt will be blocked.

## Quick takeaways

- Keep the browser's native phishing and malware protection enabled before evaluating an add-on.
- Approve an extension only after reviewing its publisher, requested access, privacy information, and support lifecycle.
- Prefer the narrowest site access that still supports the documented function.
- Pilot the control with an authorized test or reporting workflow, not with a live suspicious URL.
- Record an owner, support route, and removal path so the add-on does not become an unmanaged browser exception.

## Scope and prerequisites

This guide covers a browser-local warning layer for managed workstations. It does not compare products, configure a particular vendor console, or replace [a layered phishing-protection program](/learning/anti-phishing-program). A browser warning can help interrupt a risky visit, but the phishing definition still includes the deceptive request and the action it tries to obtain, as [NIST's phishing glossary](https://csrc.nist.gov/glossary/term/phishing) explains.

Before rollout, name the browser owner, the managed-device population, the approved extension source, and the support contact. Keep the browser current. If your organization manages Chrome, its administrator can allow or block extensions based on requested permissions through its documented [extension policy controls](https://support.google.com/chrome/a/answer/9867568?hl=en). For unmanaged devices, the user still needs a written approval and removal path.

Do not turn off a native warning layer to make a new add-on work. Chrome documents phishing and malware detection as enabled by default and says its Safe Browsing warnings can cover phishing, malware, unwanted software, and social-engineering sites in its [unsafe-site warning guidance](https://support.google.com/chrome/answer/99020?hl=en). Other browsers have different settings and policy controls, so use their current official documentation for the equivalent baseline.

## Choose the implementation approach

Use the native browser protection when it is already centrally managed and meets the immediate need. Consider an add-on only when it adds a documented function your organization has approved, such as an additional warning or reporting workflow, without requesting access that is disproportionate to that function.

Permission review is part of the security decision. Chrome's extension documentation explains that access to data on all visited websites can allow an extension to read, request, or modify page data, while access limited to listed sites is narrower. Read the current [Chrome Web Store permission guidance](https://support.google.com/chrome_webstore/answer/186213?hl=en) beside the extension's own privacy notice and support documentation. The permission warning does not by itself prove an extension is malicious, but it identifies access that needs a business justification.

If the add-on is intended for Firefox, verify the same decision in Firefox's current [optional-permissions documentation](https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions). It describes reviewing and changing optional permissions in the Add-ons Manager. Do not assume that a permission label or control works the same way in another browser.

![Decision card showing the setup sequence: native browser protection, approved extension choice, permission and privacy review, authorized validation, then keep, tune, or remove.](/images/editorial/phishing-protection-browser-add-on/browser-protection-decision-card.svg "1440x810")

*Source: Original Palisade procedure informed by [Chrome's extension permission guidance](https://support.google.com/chrome_webstore/answer/186213?hl=en) and [CISA browser-security guidance](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf). [Open the full-size decision card](/images/editorial/phishing-protection-browser-add-on/browser-protection-decision-card.svg). This card is a setup procedure, not a verdict about a website or extension.*

## How to configure a phishing protection browser add on

### 1. Confirm the native browser baseline

Ask the browser or endpoint owner to confirm that the supported browser is current and its documented phishing and malicious-download warnings remain enabled. Record the browser version range and the policy owner. This avoids treating an extension as a substitute for a security feature already provided by the browser.

### 2. Approve the publisher and install source

Use the organization-approved browser store or managed deployment path. Match the publisher to the approved vendor record, read the privacy and support information, and reject unsigned packages, copied links, and installs prompted by a pop-up. CISA's browser-security guidance recommends applying browser configuration guidance and identifies malicious advertising and redirects as browser risks in its [securing web browsers guide](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf).

### 3. Review access before enabling the add-on

Compare each requested permission with the documented function. Prefer access only when selected or on approved sites when that is sufficient. Escalate broad access to all sites, browsing history, clipboard data, or proxy and VPN behavior for a privacy and security review. Chrome notes that site-access changes do not cover extensions that alter lower-level network access through VPN or proxy settings in its [extension-management documentation](https://support.google.com/chrome/answer/2664769?hl=en).

```yaml
approval_record:
  browser_baseline: "documented native protection enabled"
  publisher_verified: true
  requested_access: "record each permission and its business reason"
  privacy_review: "approved policy and data-handling terms"
  pilot_owner: "named browser or endpoint owner"
  rollback: "disable or uninstall through the approved management path"
```

This is an approval record format, not a browser configuration. Do not copy account-specific policy values from another organization.

### 4. Pilot without visiting a real suspected phishing site

Use an authorized training simulation, a browser vendor's safe reporting path, or a managed test page approved by your security team. Check that the warning or reporting route reaches the expected owner and that legitimate business sites continue to work. Do not use a live suspicious URL as a test case, and do not ask staff to bypass a warning to establish whether the add-on works.

### 5. Document the support and rollback path

Record who can disable or remove the add-on, how an employee reports a false positive, and how the team restores browser access if an update causes an outage. Preserve the native baseline unless the authorized browser owner deliberately changes it. If an extension becomes unsupported or damaged, use the approved removal path and return to the browser-native baseline while the owner reviews the next step.

## How to validate the setup

Validate the setup in four layers. First, confirm the browser or management policy shows the native protection and approved extension in the intended state. Second, compare the actual permissions against the signed-off approval record. Third, run the authorized harmless simulation or reporting workflow and record the observed warning, report, or support action. Fourth, review help-desk tickets and browser telemetry, where your organization lawfully collects it, for breakage and false positives during the pilot.

For the browser layer, these are implementation and operating checks, not DNS, message-header, or DMARC validation. Browser protection does not replace the sender-side controls described in [email authentication and phishing protection](/learning/what-is-phishing), and it cannot establish why an individual email was delivered. If someone has already interacted with a suspicious page, use [the post-click response procedure](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) rather than relying on the add-on's presence as incident evidence.

## Troubleshooting

### The add-on asks for more access than the documented function needs

Pause the rollout. Compare the permission with the vendor documentation, then request an approved explanation or choose a control with a narrower documented scope. Do not grant broad site access simply because the extension is marketed as security software.

### A legitimate site breaks during the pilot

Capture the URL category, timestamp, browser version, and extension version without collecting credentials or page contents. Follow the approved support process, and disable or remove the add-on if access cannot be restored safely. Keep the browser's native protection enabled while the issue is investigated.

### The browser warns about a site but a user wants to continue

Treat the warning as a stop signal for the user, not proof that an administrator can safely override it. Verify the request through a known, separate service path. Chrome explicitly recommends not visiting a site when it presents a dangerous-site warning in its [Safe Browsing warning guidance](https://support.google.com/chrome/answer/99020?hl=en).

### The extension becomes unsupported or corrupted

Use the approved management path to disable or remove it and return to the native browser baseline. Replace an unsupported extension only after the same publisher, permission, privacy, pilot, and rollback review used for the original approval.

## Sources and further reading

- [Google Chrome Help: manage warnings about unsafe sites](https://support.google.com/chrome/answer/99020?hl=en)
- [Google Chrome Web Store Help: permissions requested by apps and extensions](https://support.google.com/chrome_webstore/answer/186213?hl=en)
- [Google Chrome Enterprise Help: configure ExtensionSettings policy](https://support.google.com/chrome/a/answer/9867568?hl=en)
- [CISA: Securing Web Browsers and Defending Against Malvertising](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf)

## Frequently asked questions

### Do I need an add-on if the browser already warns about phishing?

Not always. Start with the native warning layer and the browser-management controls already available. Add an extension only when it has a documented, approved function that fills a specific gap and its access can be justified.

### Can a browser extension prove that a website is safe?

No. A warning or lack of a warning is not a complete safety verdict. Keep independent verification, endpoint controls, identity protections, and incident-response procedures in place.

### Should an anti-phishing add-on have access to every website?

Only when that broad access is necessary for the approved, documented function and has passed the required privacy and security review. Prefer narrower access when it can deliver the intended protection.

### How should I test a browser phishing-protection add-on?

Use an authorized harmless simulation, a documented reporting workflow, or another approved test. Do not visit a live suspicious URL, bypass a browser warning, or expose staff to an uncontrolled phishing page for testing.

### What should I do if someone already entered credentials on a suspicious page?

Treat the event as an incident and follow the organization's response process. Reset exposed credentials through a known legitimate path, review sign-ins, and use the [post-click phishing response guide](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) for the immediate evidence-led steps.