Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team.

Overview: In iOS Chrome, the Reader Mode WebState delegate unconditionally allows media permission prompts, bypassing parental control blocks. Furthermore, Reader Mode distillation does not sanitize inline event handlers and lacks a Content Security Policy (CSP). This allows a malicious page to execute scripts in Reader Mode and trigger camera/microphone permission prompts for supervised users.

Affected files:

• ios/chrome/browser/reader_mode/model/reader_mode_web_state_delegate.mm
• ios/chrome/browser/reader_mode/model/reader_mode_content_tab_helper.mm
• ios/chrome/browser/web/model/web_state_delegate_browser_agent.mm

Estimated timestamp from git blame: 2025-07-28

Description

A potential vulnerability exists in iOS Chrome where supervised users can bypass parental “Block” settings for Camera and Microphone permissions by using Reader Mode.

When a page is distilled for Reader Mode, Chrome utilizes a modified version of Readability.js (third_party/readability/modded_src/Readability.js). While this script strips out <script> tags, it does not sanitize inline event handlers such as onerror on <img> tags. Subsequently, ReaderModeDistillerViewer::OnArticleReady wraps the distilled content in an HTML template via GetArticleTemplateHtml. Because it passes use_offline_data=false, no Content Security Policy (CSP) is injected into the template to prevent inline script execution.

The resulting HTML is loaded into a secondary WebState using LoadData, maintaining the attacker’s original URL. This WebState uses ReaderModeWebStateDelegate, which implements HandlePermissionsDecisionRequest by unconditionally returning web::PermissionDecisionShowDefaultPrompt. This skips the IsMicOrCameraAccessSubjectToParentalControls check that is correctly enforced by the standard WebStateDelegateBrowserAgent.

As a result, a script executing via an inline event handler in Reader Mode can call navigator.mediaDevices.getUserMedia(), bypassing the silent parental block and presenting the child with a native iOS permission prompt. If the child taps “Allow”, the attacker’s origin is granted access.

Potential Reproduction Steps

(Note: These are suggested steps based on code analysis; our tooling agent does not yet have the ability to run code to provide a working proof of concept).

1. Configure a supervised Chrome profile (via Family Link) on an iOS device, setting Camera and Microphone permissions to ‘Block’.
2. Host an HTTPS page eligible for Reader Mode containing a payload like: <img src="x" onerror="navigator.mediaDevices.getUserMedia({video:true})">.
3. Navigate to the page on the supervised iOS device and enter Reader Mode.
4. Observe that the onerror handler executes and triggers a native iOS permission prompt (e.g., ‘“attacker.com” Would Like to Access the Camera’).
5. Tapping ‘Allow’ grants the permission, bypassing the intended parental block.

Suggested Fix

1. Enforce Parental Controls in Reader Mode: Update ReaderModeWebStateDelegate::HandlePermissionsDecisionRequest to either perform the IsMicOrCameraAccessSubjectToParentalControls check directly or forward the permission request to the original_web_state_’s delegate to ensure consistent policy enforcement.
2. Enforce CSP in Reader Mode: Consider injecting a strict Content Security Policy for iOS Reader Mode (e.g., by modifying how GetArticleTemplateHtml handles CSP injection) to proactively block inline scripts (unsafe-inline) from executing in distilled content.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.