Dev

[MWG-Logan]

No description provided.

The best way to fix the problem is to add a permissions block at the root of the workflow file (just under the name and prior to the on: block, or right after the on: block), specifying only the minimum permissions required. In most cases, contents: read is sufficient for build/test jobs. If all steps in this workflow only need to checkout code and upload artifacts, contents: read suffices. Add this block to the top of .github/workflows/build-and-test.yml. No other steps, methods, imports, or variable definitions are required.

---

To fix the problem, you need to add a permissions block to the workflow. Since the shown job only fetches a Google API token and does not interact with the GitHub API for creating/modifying content or PRs, it needs a minimal permissions grant—contents: read or possibly even none in some cases. The safest fix is to add permissions: contents: read at the workflow root, which will ensure the job token can only read repository contents and cannot perform any write operations. This block should be inserted just after the workflow name and before the on: key.

---

To fix the problem, add an explicit permissions block at the workflow root (just after the name: and before on:) to set the least privilege required for the jobs. A minimal safe starting point is contents: read. If any jobs require elevated permissions (such as uploading release assets, which may need contents: write), you can specify more granular permissions in those jobs, but for this fix, set permissions: contents: read at the top level. This will restrict the GITHUB_TOKEN to read-only by default for all jobs unless overridden.

In .github/workflows/publish-on-chrome-webstore.yml, add the following at the top:

permissions:
  contents: read

This change does not alter the functionality of the workflow, but rather secures it by defining the permissions scope explicitly.

---

To address this issue, add a permissions: block to the workflow YAML (.github/workflows/publish-on-chrome-webstore.yml). The best practice is to add the block at the top level, so it applies to all jobs in the workflow, unless some jobs specifically require different, broader permissions. In this case, since the jobs appear to primarily read repository contents and upload release artifacts (actions which require contents: read and contents: write), you may set contents: read at workflow level as the starting point, then add broader permissions for jobs that require them (e.g., download-published-crx for uploading release assets may need contents: write). For a minimal fix, simply add permissions: contents: read at the workflow level.

This change should be made at the beginning of the workflow file, after the name: and before the on: block, as shown in the example. No additional dependencies or method changes are required.

---

To fix this problem, you should add an explicit permissions block at either the workflow or job level. Since all jobs here are relevant to publishing/deploying (no mention of multiple jobs or jobs requiring different sets of permissions), you can specify the block at the top level for clarity and security. The minimal required permission for read-only repository access is contents: read. However, if any step of the job needs more (for example, to create releases, upload artifacts, or interact with pull requests), you may need to extend these. According to the steps shown—where the job checks out the repository and accesses secrets, but does not modify repository contents—contents: read should be sufficient.

You will add the following to the top of the workflow file, after the name: line, to constrain the GITHUB_TOKEN permissions:

permissions:
  contents: read

This should be line 2, shifting all subsequent lines down by one.

---

The best way to fix the problem is to explicitly declare a top-level permissions block in the workflow YAML file, granting the least amount of privilege required for the workflow to succeed. For most of the steps in this workflow, write permission to contents is required (e.g., creating releases, uploading assets). In general, start with contents: write at the workflow level. If some jobs/steps need even less, consider scoping permissions to jobs; however, no evidence is shown here for finer granularity. Add the block right after the workflow name and before the on: key, following YAML conventions, as per GitHub Actions documentation. No additional imports or external libraries are required.

---

[Copilot]

Pull Request Overview

This PR introduces comprehensive webhook functionality, test infrastructure, improved configuration management, and enhanced development/deployment tooling for the Check extension.

• Adds a unified webhook system supporting multiple event types (detection alerts, false positives, page blocks, rogue app detection)
• Implements test infrastructure with Chrome API mocks and configuration persistence tests
• Refactors configuration management to centralize customRulesUrl and improve user settings persistence
• Enhances deployment with GitHub Actions workflows and enterprise policy updates

Reviewed Changes

Copilot reviewed 39 out of 39 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
scripts/modules/webhook-manager.js	New webhook management system with unified payload structure for all event types
scripts/modules/config-manager.js	Refactored config persistence to save only user overrides and migrate legacy settings
scripts/modules/detection-rules-manager.js	Added configuration reload functionality
scripts/content.js	Performance optimizations with regex caching, page source caching, and webhook integration
scripts/background.js	Integrated webhook manager and delegated webhook sending to centralized manager
scripts/blocked.js	Added false positive reporting functionality with webhook support
tests/config-persistence.test.js	New test suite for configuration persistence and enterprise policy precedence
tests/helpers/chrome-mock.js	Chrome API mock implementation for testing
tests/helpers/logger-mock.js	Logger mock for test environment
test-pages/*.html	Test pages for manual phishing detection validation
options/options.html	Added generic webhook configuration UI
options/options.js	Integrated webhook settings management
rules/detection-rules.json	Updated regex patterns with escaped forward slashes and improved detection logic
manifest.json	Added file:// protocol support for local testing
config/managed_schema.json	Added genericWebhook schema for enterprise policies
docs/webhooks.md	Comprehensive webhook documentation with payload examples
docs/settings/general.md	Documentation for false positive webhook configuration
enterprise/admx/en-US/Check-Extension.adml	Formatting improvements and companyURL policy addition
enterprise/*.ps1	New PowerShell scripts for testing and removal of extension policies
.github/workflows/*.yml	New CI/CD workflows for building, testing, and publishing releases
blocked.html	Added false positive reporting button and anti-flicker loading state
popup/popup.css	Theme-aware loading screen colors
package.json	Added test scripts for running test suites

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The webhook URL and enabled state are not validated before sending the webhook. The code should validate that the URL is a valid HTTPS URL to prevent accidentally sending sensitive detection data over insecure HTTP connections.

Add validation like:

if (genericWebhook.url && !genericWebhook.url.startsWith('https://')) {
  console.error("Webhook URL must use HTTPS");
  return;
}

[Copilot]

The reportFalsePositive function sends potentially sensitive detection details including page content, browser information, and screen resolution to an arbitrary webhook URL. There's no user consent or warning about what data is being sent when they click the "Report False Positive" button.

Consider adding a confirmation dialog that clearly explains what data will be sent, or providing a privacy notice near the button.

[Copilot]

Empty catch blocks silently swallow errors, making debugging difficult. The webhook sending failures in the content script use .catch(err => { logger.warn(...) }) pattern, but here the error is completely ignored.

Consider at least logging the error:

} catch (e) {
  logger.warn("Failed to analyze stylesheets:", e);
}

Suggested change

	} catch (e) {}
	} catch (e) {
	logger.warn("Failed to analyze stylesheets:", e);
	}

[Copilot]

The generic webhook configuration lacks input validation in the UI. The webhook URL should be validated to ensure it's a valid HTTPS URL before saving. Currently, users could enter an invalid URL or an insecure HTTP URL, which would cause runtime errors or security issues.

Add URL validation in the save configuration logic similar to how other URLs are validated in the codebase.

[Copilot]

[nitpick] The test uses a mock fetch that always returns ok: false, status: 404. This setup is repeated in multiple test suites, creating code duplication. Consider extracting this into a helper function in the test setup or creating a reusable mock fetch fixture.

For example:

function createMockFetch(response = { ok: false, status: 404 }) {
  return async () => response;
}

[Copilot]

The regex patterns in the detection rules JSON file use escaped forward slashes (\/) which are unnecessary in JSON strings. JSON does not require escaping forward slashes, and while it's technically valid, it adds unnecessary complexity and makes the patterns harder to read.

For example, "^https:\\/\\/login\\.microsoftonline\\.(com|us)$" should be "^https://login\\.microsoftonline\\.(com|us)$".

Consider simplifying these patterns for better maintainability.

[Copilot]

The regex pattern uses a greedy quantifier .{0,2000} which could cause performance issues when matching against large HTML documents. Consider using a non-greedy quantifier .{0,2000}? or a more specific pattern to improve regex performance and prevent potential regex denial-of-service (ReDoS) scenarios.

Suggested change

	"pattern": "(?:microsoft|office|365).{0,2000}(?:login|password|signin).{0,500}form.{0,200}action(?!.*login\\.microsoftonline\\.com)(?!.*\\.auth/login/)(?!.*azure\\s+static\\s+web\\s+apps)(?!.*easy\\s+auth)",
	"pattern": "(?:microsoft|office|365).{0,2000}?(?:login|password|signin).{0,500}form.{0,200}action(?!.*login\\.microsoftonline\\.com)(?!.*\\.auth/login/)(?!.*azure\\s+static\\s+web\\s+apps)(?!.*easy\\s+auth)",

[Copilot]

The manifest.json adds support for "file:///*/*" URLs in content scripts. This allows the extension to run on local file:// URLs, which could be a security concern as it gives the extension access to the user's local file system content when viewing HTML files locally.

Consider whether this is truly necessary for the extension's functionality, or if it should be limited to specific use cases (like developer testing). If it's only for testing, consider documenting this clearly or providing a separate development manifest.

Suggested change

	"matches": ["http://*/*", "https://*/*", "file:///*/*"],
	"matches": ["http://*/*", "https://*/*"],

[Copilot]

Unused function analyzeStylesheets.

Suggested change

	function analyzeStylesheets() {
	if (cachedStylesheetAnalysis) return cachedStylesheetAnalysis;
	const analysis = { hasMicrosoftCSS: false, cssContent: "", sheets: [] };
	try {
	const styleSheets = Array.from(document.styleSheets);
	for (const sheet of styleSheets) {
	const sheetInfo = { href: sheet.href || "inline" };
	if (sheet.href?.match(/msauth|msft|microsoft/i)) {
	analysis.hasMicrosoftCSS = true;
	}
	try {
	if (sheet.cssRules) {
	analysis.cssContent +=
	Array.from(sheet.cssRules)
	.map((r) => r.cssText)
	.join(" ") + " ";
	sheetInfo.accessible = true;
	}
	} catch (e) {
	sheetInfo.accessible = false;
	}
	analysis.sheets.push(sheetInfo);
	}
	} catch (e) {}
	cachedStylesheetAnalysis = analysis;
	return analysis;
	}