Back to Signal Feed
CodeTracked since May 20, 2026

Block URL policy bypasses for data: and blob: schemes

This change tightens browser URL filtering by denying `data:` URLs when domain allow/prohibit rules are configured and by validating `blob:` URLs so they only pass when their embedded origin passes existing domain checks, preventing special-scheme bypass of configured navigation policies.

browser-usesecurity_watchdogallowed_domainsprohibited_domains

What Happened

  • This change tightens browser URL filtering by denying `data:` URLs when domain allow/prohibit rules are configured and by validating `blob:` URLs so they only pass when their embedded origin passes existing domain checks, preventing special-scheme bypass of configured navigation policies.
  • This change tightens browser URL filtering by denying `data:` URLs when domain allow/prohibit rules are configured and by validating `blob:` URLs so they only pass when their embedded origin passes existing domain checks, preventing special-scheme bypass of configured navigation policies.
  • 1 evidence item attached for review.

What is Different

Before

Scattered source updates, isolated context, and manual follow-up across multiple feeds.

Now

Added explicit enforcement in the security URL policy path for special schemes, so `allowed_domains`/`prohibited_domains` filtering now covers `data:` and restricted `blob:` URLs consistently, with added regression tests for allowlist, prohibitlist, unrestricted-session, and opaque/internal blob edge cases.

Why Track This

Why It Matters

Browser-automation operators and product users who run sessions with URL allow/prohibit controls will avoid silent policy bypasses through `data:` and malformed `blob:` links, which lowers the chance of unintended page access during controlled browsing. It accomplishes this by rejecting those special-scheme URLs unless they satisfy strict origin checks, while unrestricted sessions remain unchanged; teams should watch for legitimate workflows that depend on `blob:`/`data:` URLs to avoid accidental over-blocking.

Impact

Browser-automation operators and product users who run sessions with URL allow/prohibit controls will avoid silent policy bypasses through `data:` and malformed `blob:` links, which lowers the chance of unintended page access during controlled browsing. It accomplishes this by rejecting those special-scheme URLs unless they satisfy strict origin checks, while unrestricted sessions remain unchanged; teams should watch for legitimate workflows that depend on `blob:`/`data:` URLs to avoid accidental over-blocking.

What To Watch Next

  • Watch whether browser-use becomes a repeated pattern.
  • Track follow-up changes around AI Security.
  • Compare future signals against this evidence trail.
  • Re-check risk flags: watch_for_false_positives_on_special_scheme_content, monitor_blob_internal_origin_rejections_in_real_workflows.
Open Topic TimelineOpen Technical EventOpen Original Sourcewatch_for_false_positives_on_special_scheme_content / monitor_blob_internal_origin_rejections_in_real_workflows / confirm_unrestricted_sessions_keep_previous_behavior

Supporting Evidence

GITHUB PULL REQUESTHigh Trust

browser-use/browser-use PR #4850: fix(security): block special-scheme domain bypasses

Fixes #4763 by blocking special-scheme bypasses in domain filtering: `data:` is denied under policy, and `blob:` inherits and validates its embedded origin (rejecting opaque/internal forms) while leaving unrestricted sessions behavior unchanged.