Chrome extension permission · declarativeNetRequest (DNR) · request rules

Chrome declarativeNetRequest (DNR): Block & Redirect Rules, MV3 Risks & Updates

Risk: High
Summarize with ChatGPT

The Chrome extension declarativeNetRequest permission unlocks the DNR API: declarative rules that can allow, block, upgrade schemes, or redirect HTTP(S) requests before they complete. It is the backbone of most Manifest V3 content blockers and many privacy filters.

DNR is not arbitrary per-request JavaScript in the network path—Chrome validates rule shapes and enforces limits—but rule sets can still change when the extension updates or fetches remote lists. Read the full manifest: DNR plus read-all-sites, scripting, or proxy-style powers is a different trust decision than a standalone filter from a known vendor.

Quick summary: declarativeNetRequest (DNR) in 30 seconds

  • declarativeNetRequest (DNR) is the Manifest V3-era API for structured allow, block, redirect, and upgrade rules—think ad blockers, tracker filters, parental controls, and enterprise allowlists.
  • It replaces much of the old webRequest blocking model with declared rule sets and browser-enforced limits (static vs dynamic rule budgets, update cadence).
  • Supply-chain risk is real: remote or auto-updated rule lists can steer traffic—phishing domains, affiliate injectors, or silent header stripping—without feeling like a “proxy” install.
  • Trust the publisher and how rules are sourced; re-read the permission diff after updates, especially when DNR appears next to broad host or scripting powers.

Real-world lens: reputable blockers vs rule-list supply chain

Major open-source blockers publish filter lists you can inspect; a random “ad blocker” with opaque remote rules is a different risk profile—DNR is the engine, but whoever controls the lists controls where your browser can go.

Combine DNR with raw network access, proxy-style routing, content scripts, or read-all-sites permissions only when the product story needs the full stack; otherwise treat extra powers as escalation.

What declarativeNetRequest enables (rules, redirects & upgrades)

  • Apply static rules packaged with the extension and, where permitted, dynamic or session rules that adjust at runtime—subject to documented caps and browser version behavior.
  • Block or allow URLs by pattern, resource types, and initiators; redirect or upgrade traffic (for example HTTP→HTTPS) in ways that materially change what loads in the tab.
  • Pair with host permissions or other APIs in composite designs: the effective power is the combination of DNR, scripting, and network access, not the DNR line alone.

Abuse scenarios: phishing redirects, breakage & insider risk

  • Tampered or malicious rule updates can redirect sign-in flows to phishing clones, strip safety headers, or allow malware domains while blocking security vendors—often blamed on “the site is broken.”
  • Over-aggressive filters break payroll, SSO, or healthcare portals in subtle ways, driving unsafe workarounds (disabling protection globally) instead of scoped fixes.
  • Enterprise blind spots: rules that target internal hostnames, telemetry endpoints, or SaaS APIs can exfiltrate metadata or weaken monitoring when bundled with other extension powers.

Official docs: Chrome DNR reference, MV3 migration & permission warnings

Chrome declarativeNetRequest API & Manifest V3 context

Google’s reference documents rule types, static and dynamic rule limits, updateRuleOptions, and how DNR interacts with other extension surfaces—start here before trusting marketing that says ‘we only block ads.’Sources: Chrome — declarativeNetRequest API · Chrome — Migrate to Manifest V3

Permission warnings and declare-permissions explain what users see at install time; cross-check them against the full manifest, not a single line.Sources: Chrome — Declare permissions · Chrome — Permission warnings

Ecosystem & policy context (block lists, advocacy, filter syntax)

Civil-society commentary on MV3 and content blocking highlights trade-offs between performance, privacy, and who controls rule delivery—read it alongside primary Chrome documentation.Sources: EFF — Google’s Manifest V3 (Dec 2021 deep link)

Filter-list authors document syntax and maintenance practices; useful background for understanding how declarative rules map to real-world subscriptions.Sources: AdGuard — How to create ad filters · MDN — declarativeNetRequest (Firefox)

Practical tips: rule transparency, updates & enterprise inventory

  • Prefer blockers and filters with open rule sources, reproducible builds, and a clear explanation of who can push remote lists.
  • Watch update cadence and permission diffs—new DNR plus unexpected host or scripting access deserves a pause.
  • Keep a clean diagnostic profile without heavy filters when troubleshooting breakage; compare behavior before blaming the website.
  • For orgs: inventory extensions with DNR, correlate rule changes to updates, and policy-separate tools that can touch internal zones.

Last reviewed: March 2026. Educational overview only—not legal advice; verify rule limits and APIs against current Chrome documentation.

FAQ: declarativeNetRequest, DNR rules & Manifest V3

Short answers for common searches—use with the risk and mitigation sections above for full context.

What is declarativeNetRequest used for in Chrome extensions?

It powers declarative rules to allow, block, upgrade, or redirect network requests—common in MV3 ad blockers, tracker protection, and policy filters—without the old always-on webRequest blocking listener model in typical designs.

Can DNR rules be dangerous?

Yes. Malicious or compromised rule updates can redirect you to phishing pages, weaken protections, or break critical sites. Trust and update hygiene matter as much as with any high-impact permission.

Is DNR the same as unlimited fetch to any server?

No. DNR is a structured rule engine with limits. Extensions may still combine it with host permissions, scripting, or other APIs for outbound calls—read every line in the install dialog.

How is DNR different from the legacy webRequest blocking API?

MV3 moved most consumer blocking to declared rules evaluated by the browser, reducing long-lived blocking listeners. Capabilities and ergonomics differ by version; always check current Chrome docs for rule budgets and update APIs.

What should teams monitor for extensions with DNR?

New DNR grants, changes to static or remote rule sets on update, overlap with sensitive internal hostnames, and pairing with broad site or script access that could exfiltrate what filters observe.

Further reading: DNR docs & related eSafe guides

Pair Chrome’s API reference with every Chrome extension permission on the install sheet—especially network, proxy traffic, scripts, and broad host access.

Related extension guides

These topics often show up together in real extensions and abuse reporting—reading them as a set makes it easier to judge combined risk.

Browse all extension power guides

Audit what is installed

Pair least-privilege installs with a periodic review—especially after any extension update.

Add to Chrome