SECURITY.md - devtools/devtools-frontend - Git at Google

 # Chrome DevTools Frontend Security Policy & Threat Model

 This document outlines the security goals, boundaries, and threat model for the Chrome DevTools frontend.

 ## Architectural Philosophy & Trust Boundaries

 Chrome DevTools is a privileged web app running in a sandboxed renderer process, communicating via the Chrome DevTools Protocol (CDP).

 * **Intended Capabilities:** DevTools is designed to inspect, mutate, and control debug targets (tabs, workers, remote nodes). Actions like code execution (Console, Snippets) or filesystem binding are intended behaviors, not vulnerabilities.
 * **Data Processing:** The frontend does not execute untrusted user-space code in its own processes. It may instruct the debug target to execute code. It parses structured data from the CDP target. While a target page may be compromised, DevTools must safely display this data without escalating privileges to the browser process or host OS.

 ## Threat Model Boundaries

 ### Inside Threat Model
 * Compromising the DevTools frontend renderer process.
 * Compromising the CDP backend via tampered protocol messages.
 * Unauthorized exfiltration of sensitive local files or user data outside the debugging scope.
 * Triggering Chrome memory corruption exploits.

 ### Outside Threat Model
 * **Social Engineering:** Convincing developers to paste payloads into the Console or connect to malicious remote debugging ports.
 * **Legitimate Data Exposure:** Displaying local user data, cookies, tokens, or auth headers within UI panels.
 * **Local Data Persistence:** Saving user-initiated traces, heaps, profiles, or logs to disk.
 * **Correctness & Availability:** Stale, misleading, or missing UI information (classified as functional bugs).
 * **Disabled-by-default Experimental Features:** Experimental features or capabilities that are disabled by default, e.g. requiring a command-line flag to be activated, or a specific runtime setting within DevTools to be manually turned on.

 ## Specific Severity Classification Rules (S1–S4)

 ### S0 (Critical)
 * Exploits affecting users without Chrome DevTools being open.

 ### S1 (High)
 * Exploits requiring only standard user actions within an open DevTools window.
 * HTML injection or rendering untrusted content within the DevTools UI.
 * Persistent exploits (e.g., manipulating service worker source code).

 ### S2 (Medium)
 * Exploits strictly dependent on explicit, non-standard user interactions.
 * Targets leveraging parsing flaws to compromise another renderer process without escaping the browser sandbox.

 ### S3 (Low)
 * Exploits requiring a malicious, highly-privileged Chrome Extension to interact with DevTools APIs, including bypassing extension host policy.
 * Spoofing links in DevTools that navigate to restricted internal URLs (e.g., `chrome://`).
 * Vulnerabilities requiring specific command-line arguments, third-party tools, or loading tampered local files.
 * Other exploits in features which are marked as experimental, but enabled by default.

 ## Specific Aspects

 ### AI & LLM Features
 * **Trusted Backend:** The remote Google LLM backend is trusted; data sent to it is not an exfiltration vulnerability.
 * **AI Safety:** Prompt injection, jailbreaks, or offensive/incorrect AI output are functional bugs, not vulnerabilities.
 * **Exception:** Prompt injection is only a vulnerability if it crosses cross-origin boundaries or executes unauthorized CDP commands.

 ### Side-Effect Free Evaluation
 * Side-effect free JavaScript evaluation is a best-effort developer heuristic to prevent accidental state changes, not a security boundary. Bypassing it to cause side effects on the debugged page is not a vulnerability.
	# Chrome DevTools Frontend Security Policy & Threat Model

	This document outlines the security goals, boundaries, and threat model for the Chrome DevTools frontend.

	## Architectural Philosophy & Trust Boundaries

	Chrome DevTools is a privileged web app running in a sandboxed renderer process, communicating via the Chrome DevTools Protocol (CDP).

	* Intended Capabilities: DevTools is designed to inspect, mutate, and control debug targets (tabs, workers, remote nodes). Actions like code execution (Console, Snippets) or filesystem binding are intended behaviors, not vulnerabilities.
	* Data Processing: The frontend does not execute untrusted user-space code in its own processes. It may instruct the debug target to execute code. It parses structured data from the CDP target. While a target page may be compromised, DevTools must safely display this data without escalating privileges to the browser process or host OS.

	## Threat Model Boundaries

	### Inside Threat Model
	* Compromising the DevTools frontend renderer process.
	* Compromising the CDP backend via tampered protocol messages.
	* Unauthorized exfiltration of sensitive local files or user data outside the debugging scope.
	* Triggering Chrome memory corruption exploits.

	### Outside Threat Model
	* Social Engineering: Convincing developers to paste payloads into the Console or connect to malicious remote debugging ports.
	* Legitimate Data Exposure: Displaying local user data, cookies, tokens, or auth headers within UI panels.
	* Local Data Persistence: Saving user-initiated traces, heaps, profiles, or logs to disk.
	* Correctness & Availability: Stale, misleading, or missing UI information (classified as functional bugs).
	* Disabled-by-default Experimental Features: Experimental features or capabilities that are disabled by default, e.g. requiring a command-line flag to be activated, or a specific runtime setting within DevTools to be manually turned on.

	## Specific Severity Classification Rules (S1–S4)

	### S0 (Critical)
	* Exploits affecting users without Chrome DevTools being open.

	### S1 (High)
	* Exploits requiring only standard user actions within an open DevTools window.
	* HTML injection or rendering untrusted content within the DevTools UI.
	* Persistent exploits (e.g., manipulating service worker source code).

	### S2 (Medium)
	* Exploits strictly dependent on explicit, non-standard user interactions.
	* Targets leveraging parsing flaws to compromise another renderer process without escaping the browser sandbox.

	### S3 (Low)
	* Exploits requiring a malicious, highly-privileged Chrome Extension to interact with DevTools APIs, including bypassing extension host policy.
	* Spoofing links in DevTools that navigate to restricted internal URLs (e.g., `chrome://`).
	* Vulnerabilities requiring specific command-line arguments, third-party tools, or loading tampered local files.
	* Other exploits in features which are marked as experimental, but enabled by default.

	## Specific Aspects

	### AI & LLM Features
	* Trusted Backend: The remote Google LLM backend is trusted; data sent to it is not an exfiltration vulnerability.
	* AI Safety: Prompt injection, jailbreaks, or offensive/incorrect AI output are functional bugs, not vulnerabilities.
	* Exception: Prompt injection is only a vulnerability if it crosses cross-origin boundaries or executes unauthorized CDP commands.

	### Side-Effect Free Evaluation
	* Side-effect free JavaScript evaluation is a best-effort developer heuristic to prevent accidental state changes, not a security boundary. Bypassing it to cause side effects on the debugged page is not a vulnerability.