M1021 Restrict Web-Based Content: Web Controls That Cut Drive-by and Phishing Risk

Most intrusions still start with a browser fetching something it should never have reached, and MITRE ATT&CK M1021 Restrict Web-Based Content is the mitigation that decides what the browser and the network are allowed to reach, download and run. ATT&CK v20 describes M1021 as enforcing policies and technologies that limit access to potentially malicious websites, unsafe downloads and unauthorised browser behaviour, through URL filtering, download restrictions, script blocking and extension control. In v20 it is linked to 31 techniques and sub-techniques across initial access, execution, credential access, command and control and exfiltration. This guide reads M1021 from the ATT&CK point of view: which techniques it genuinely blunts, where it leaves gaps and which other mitigations close them, how to roll it out in a sensible order and how to prove coverage. It is for detection engineers, endpoint and network owners and security architects. How to choose and run a gateway is covered in the Secure Web Gateway and Web Filtering Guide; this page does not repeat it.

Key takeaways

• M1021 is a bundle, not a product. ATT&CK groups five measures under it: web proxy filtering, DNS filtering, Content Security Policy on your own web apps, browser feature control and alerting on web-based threats. Each covers different techniques.
• Its strongest coverage is initial access and egress. Drive-by Compromise (T1189), the Phishing family (T1566), Web Service command and control (T1102) and Exfiltration Over Web Service (T1567) are where the per-technique guidance is most specific.
• Consent control is part of M1021. ATT&CK lists blocking end-user consent to OAuth applications under M1021 for Steal Application Access Token (T1528), which is an identity control as much as a web one.
• HTML smuggling is not mapped to M1021. In ATT&CK v20, HTML Smuggling (T1027.006) is mitigated only by M1048 Application Isolation and Sandboxing, because the payload is built inside the browser and never crosses the gateway as a file.
• Measure it per technique. Track block rates for risky file types, extension allow-list compliance, the share of traffic leaving through the filtered path and the count of user-consented OAuth grants, rather than one "web filter enabled" tick box.

What M1021 covers in ATT&CK v20

The ATT&CK M1021 page lists five implementation measures. They are worth separating, because teams often deploy the first and assume the rest.

D3FEND relates M1021 to seven defensive techniques: DNS Allowlisting (D3-DNSAL), DNS Denylisting (D3-DNSDL), File Analysis (D3-FA), Inbound Traffic Filtering (D3-ITF), Network Traffic Analysis (D3-NTA), Outbound Traffic Filtering (D3-OTF) and URL Analysis (D3-UA). D3FEND itself comments that M1021 is broad in scope.

Techniques M1021 mitigates, by tactic

The table below groups the 31 v20 mappings by tactic, collapsing sub-techniques where ATT&CK gives them the same guidance. The "how it helps" column paraphrases ATT&CK's own per-technique mitigation text. Priority is an NHI Mgmt Group judgement based on how often the technique opens an intrusion.

Technique guides for most of these rows: the T1566 Phishing guide, T1204 User Execution, T1102 Web Service Defensive Guide, T1567 Exfiltration Over Web Service, MITRE ATT&CK T1528 Steal Application Access Token Guide and MITRE ATT&CK T1539 Steal Web Session Cookie.

Implementing the five measures well

Gateway and download control

• Default-deny risky file types: ATT&CK names .scr, .exe, .pif and .cpl as examples to block in transit, and CHM for T1218.001. Build the list from what the business actually downloads, then add archive inspection so zip and rar containers are opened and scanned, as ATT&CK recommends for T1204 and T1566.001.
• Browser-level download policy: where a gateway cannot see the file, the browser can still refuse it. Microsoft Edge's DownloadRestrictions policy (REG_DWORD under SOFTWARE\Policies\Microsoft\Edge) takes values 0 DefaultDownloadSecurity, 1 BlockDangerousDownloads, 2 BlockPotentiallyDangerousDownloads, 3 BlockAllDownloads and 4 BlockMaliciousDownloads; Google Chrome has an equivalent DownloadRestrictions policy. Microsoft notes that the restriction applies to downloads from page content and the "download link" menu, not to saving the page or printing to PDF.
• Egress through one path: T1102 and T1567 coverage only exists for traffic that passes the proxy. Block direct outbound HTTP and HTTPS from user subnets and servers so the filtered path is the only path. See the M1037 Filter Network Traffic guide for the network side.

DNS filtering

• Protective DNS first: refusing to resolve known malicious domains is cheap and covers every protocol, not only web. In the US federal civilian estate, CISA's Protective DNS Resolver filters queries against threat intelligence, supports encrypted DNS (DoH and DoT) and gives agencies their DNS logs. See the Protective DNS Guide.
• Sinkhole for DGA: ATT&CK notes a local sinkhole can blunt T1568.002 at reduced cost.
• Close the bypasses: block outbound port 53 and known public DoH endpoints from endpoints that should use the corporate resolver, or the filter only covers well-behaved software.

Browser feature and extension control

Browsers are listed alphabetically. Google Chrome's ExtensionSettings policy sets an installation_mode per extension or for * (all extensions without their own entry) with values allowed, blocked, force_installed, normal_installed and removed; blocked_permissions prevents extensions that request listed API permissions from installing or loading, and runtime_blocked_hosts stops extensions interacting with named sites, including cookie access and script injection. Microsoft Edge offers ExtensionInstallBlocklist, ExtensionInstallAllowlist and ExtensionSettings for the same purpose, plus content settings such as DefaultJavaScriptSetting and DefaultNotificationsSetting. The pattern ATT&CK points to for T1539 and T1555.003 is an allow-list of reviewed extensions with the rest blocked, and runtime host blocks on identity provider and admin consoles so even approved extensions cannot read their cookies. Wider browser hardening is in the Browser Security Hardening Guide.

Content Security Policy on your own applications

CSP is the only M1021 measure that protects your customers and staff when they visit your applications rather than someone else's. A policy that restricts script-src to known origins, sets frame-ancestors and limits connect-src makes injected script far harder to run and to exfiltrate from, which is the defender's side of T1189 and T1659 on sites you host. Run it in Content-Security-Policy-Report-Only mode first. See the Same-Origin Policy and Browser Security Model Guide.

Where identity fits: consent and tokens

Three of the high-priority rows (T1528, T1539 and T1550.001) are about tokens and sessions, not files. ATT&CK's M1021 text for T1528 says administrators can block end-user consent to OAuth applications and block end-user app registration, forcing admin consent. In Microsoft Entra ID, Microsoft documents two built-in user consent policies: microsoft-user-default-legacy ("Allow user consent for apps"), which lets users consent to any permission that does not need admin consent, and microsoft-user-default-low ("Allow user consent for apps from verified publishers, for selected permissions"), which limits consent to verified publishers and tenant apps for permissions you classify as low impact. Removing the self-consent policy from permissionGrantPoliciesAssigned turns user consent off. Microsoft states that by default all users can consent to permissions that do not need admin consent, so this is a setting to change deliberately. Step-by-step instructions are in How to restrict user consent to apps in Entra ID, and the wider governance model in the Consent Phishing and Illicit OAuth Grants Guide.

The Cyberhaven Chrome Extension Breach 2024 shows why this sits under M1021. An employee with publishing rights followed a phishing link to a genuine Google consent screen and authorised a malicious app; MFA did not prompt during consent, the app received a token that could publish extensions, and a malicious update was pushed to users through normal auto-update. Two M1021 controls were relevant on two sides: restricting which apps users can consent to, and an extension allow-list with update monitoring for the people who installed it.

What M1021 does not stop

Choosing where to enforce

• Small organisations: protective DNS plus managed browser policy (download restrictions, extension allow-list, SmartScreen or Safe Browsing kept on) gives most of the high-priority rows without a proxy. Turn off user OAuth consent on day one.
• Large or regulated organisations: add a forward proxy or cloud gateway with TLS inspection for file analysis and per-user policy, because T1102, T1567 and archive scanning need content visibility. TLS inspection has its own trade-offs; see the M1020 SSL/TLS Inspection guide.
• Servers and workloads: these should not browse at all. Apply an egress allow-list to named destinations rather than category filtering. It is the cheapest T1102 and T1567 coverage available and limits what a stolen workload credential can reach.

Implementation: a phased rollout

1. Inventory paths out: list every way hosts reach the internet (proxy, direct NAT, VPN split tunnel, DoH). M1021 only works on paths you control.
2. Turn on protective DNS and log it: forward resolver logs to the SIEM before blocking anything, so you have a baseline of what is queried.
3. Disable user OAuth consent: move to admin consent or the verified-publisher low-impact policy, with an admin consent request workflow so users have a route.
4. Browser policy in a pilot ring: deploy download restrictions, extension allow-listing and notification blocking to IT first. Run the extension policy as an inventory for two weeks, review what is installed, then switch * to blocked for the pilot.
5. Block file types at the gateway: start with the ATT&CK examples (.scr, .exe, .pif, .cpl, .chm, .hta) plus archives that cannot be scanned. Use warn pages before hard blocks for a week to find business exceptions.
6. Close direct egress: once the proxy carries everything, remove direct outbound web from user and server networks.
7. Roll out by ring and keep a rollback: every policy should be a single GPO, Intune profile or gateway rule set that can be reverted in minutes.

Measuring coverage

Map each high-priority row to a log source and a test, then report these metrics monthly:

• Filtered egress share: percentage of outbound web connections that traverse the proxy or protective DNS, from firewall logs. Target close to 100% for servers.
• Extension allow-list compliance: percentage of managed browsers with the default * set to blocked and no unapproved extensions present.
• User-consented OAuth grants: count of new delegated grants by users in the period. After step 3 this should trend to zero outside the approved low-impact list.
• Risky file type blocks and overrides: blocks per thousand users and the number of warn-page bypasses; rising bypasses mean the policy is out of step with the business.
• Time to block new indicators: from a threat intelligence feed entry to enforcement at DNS and proxy.
• Emulation pass rate: the share of ATT&CK test cases for T1189, T1204, T1566 and T1567 that the controls stopped in a quarterly purple team exercise.

Common failure patterns

• Filtering only the proxy-aware traffic. Servers, build agents and scripts that ignore proxy settings go straight out, so T1102 and T1567 coverage on those hosts is zero.
• Extension policy set to "allowed" by default. Chrome's documented default for installation_mode is allowed; without an explicit * block, a blocklist only stops extensions someone has already named.
• Leaving user consent open. The default lets any user grant a third-party app access to their mailbox or files, which is the path in the Cyberhaven case.
• Treating category filtering as data protection. Allowing "cloud storage" as a category allows exfiltration to any tenant of that service.
• No DNS bypass controls. Encrypted DNS to a public resolver quietly sidesteps the protective DNS layer.

Framework mapping

Related mitigations: M1031 Network Intrusion Prevention, M1037 Filter Network Traffic, M1048 Application Isolation and Sandboxing, M1017 User Training and M1033 Limit Software Installation. The MITRE ATT&CK Mitigations hub lists them all.

Practitioner checklist

• Confirm every host, including servers and build agents, reaches the web only through a filtered path.
• Run protective DNS with logs in the SIEM and block outbound port 53 and public DoH from endpoints.
• Turn off user OAuth consent or restrict it to verified publishers and low-impact permissions, with an admin request workflow.
• Set the browser extension default to blocked, allow-list reviewed extensions and block runtime access to identity and admin consoles.
• Block .scr, .exe, .pif, .cpl, .chm and .hta downloads where not needed, and scan archives.
• Set browser download restrictions by policy on every managed browser.
• Ship CSP on your own web applications, starting in report-only mode.
• Put servers and workloads on an egress allow-list rather than category filtering.
• Alert on blocked-domain hits and repeated failed downloads, and review warn-page bypasses monthly.
• Test T1189, T1204, T1566 and T1567 coverage each quarter and record the pass rate.

Standards and references

• MITRE ATT&CK: M1021 Restrict Web-Based Content
• MITRE D3FEND: URL Analysis
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Microsoft Edge DownloadRestrictions policy
• Google: Chrome Enterprise, use ExtensionSettings to manage extensions
• CISA: Protective Domain Name System Resolver
• Microsoft Learn: Web protection overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Secure Web Gateway and Web Filtering Guide · Browser Security Hardening Guide · Protective DNS Guide · Consent Phishing and Illicit OAuth Grants Guide · HTML Smuggling Guide