Browsers protect users with the same-origin policy. A page from one site cannot freely read data from another. Content Security Policies and cross-domain policy files let a site loosen those rules on purpose, for partners, CDNs and APIs it genuinely trusts.
CWE-942 describes what goes wrong when that list of trusted domains is too generous. The product uses a CSP or cross-domain policy file, but the policy includes untrusted domains the web client is allowed to talk to. MITRE classes it as a Variant and lists it as web based, applying to web servers and anything that serves such a policy.
If you ship a web application, an API that sets CORS headers, or a CSP, this one is yours.
How it happens
Most permissive policies start as a shortcut. A developer needs a front end on another origin to call an API, and the quickest way to stop the error in the console is to allow everything. Later, nobody revisits it.
MITRE's extended description points to the common pattern: wildcards under a high-level domain. A policy that trusts every subdomain of a broad domain implicitly trusts every host an attacker can create or take over beneath it. Any domain matching the wildcard expression is trusted and can perform two-way interaction with the target server.
A permissive policy can show up in several places:
- A Content Security Policy with wildcard sources in directives such as script or connect sources.
- A cross-domain policy file served from the web root that allows broad access.
- Cross-origin response headers that reflect whatever origin the request carried.
- Legacy plugin policy files that were never removed after the plugin died.
The observed CVEs on the MITRE page are mostly from the Flash and Silverlight era, and they show the shape of the problem clearly. CVE-2012-2292 is a Silverlight cross-domain policy that does not restrict access to another application, letting remote attackers bypass the Same Origin Policy. CVE-2014-2049 covers default Flash cross-domain policies that let remote attackers access user files. The plugins are gone, but the lesson about overly broad trust is not.
Here is the modern equivalent in a CSP. The vulnerable version trusts a wildcard and any HTTPS source:
# Vulnerable: any host under the wildcard, and any https origin, may be scripted or contacted
Content-Security-Policy: script-src 'self' https://*.example-cdn.net https:; connect-src *
The tighter version names the exact hosts the application needs:
# Better: exact origins only
Content-Security-Policy: script-src 'self' https://static.example-cdn.net; connect-src 'self' https://api.example.com
What an attacker gains
MITRE lists a wide set of consequences because the impact depends on what the policy was supposed to protect. With an overly permissive policy file, an attacker may be able to bypass the browser's same-origin policy and carry out many of the same actions a user could, from the user's own browser.
From the record, that includes:
- Reading application data that the same-origin policy would normally keep private.
- Executing unauthorized code or commands, when the policy governs where scripts may load from.
- Bypassing a protection mechanism, since the policy was the protection.
- Effects on confidentiality, integrity, availability and access control, varying by context.
MITRE also notes that in many cases the attack can be launched without the victim being aware of it. A user simply visits an attacker controlled page while signed in to your service, and the browser does the rest.
How to find it
The MITRE record lists automated static analysis, also known as SAST, as a way to find some instances. A scanner can read your code and configuration and flag wildcard sources and policy files that are too open.
You can also check by hand:
- Fetch your homepage and API responses and read the Content Security Policy header. Look for wildcards, bare scheme sources and overly broad domains.
- Request
/crossdomain.xmland/clientaccesspolicy.xmlon your hosts. If they exist and you have no plugin clients, ask why. - Send a request with an
Originheader set to a domain you do not control and see whether your cross-origin response headers echo it back. - List every domain in the policy and ask who controls it today. Expired domains and abandoned subdomains are a quiet risk.
A dynamic scan against a running application will catch policy headers that your source code never mentions, such as ones added by a gateway or proxy.
How to fix it
MITRE's mitigations are short and practical.
- Define a restrictive policy. Write a Content Security Policy or cross-domain policy file that lists only what the application needs. This is an attack surface reduction step, done at design time and revisited during operation.
- Avoid wildcards. Any domain that matches the wildcard is implicitly trusted. Name hosts explicitly instead.
- Harden legacy Flash policy files. If you still serve one, use meta-policy options such as master-only or none, which reduces the chance that an attacker plants extra policy files on your server.
Beyond the record, a few habits keep the list honest. Keep the allowed domains in version control so changes get reviewed. Remove entries when a partnership or integration ends. Test the policy in report-only mode before enforcing it, so you find legitimate sources you missed without breaking production.
Try it yourself
This demo walks through a dynamic scan of a web application, including the kind of header findings that surface policy problems.
Click through it at your own pace, or open it full screen.
Libraries and frameworks that set these headers for you also carry their own defaults. You can check the dependencies in your project with the free in-browser scan at gold.safeguard.sh/scan. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
Quick check
Why is a wildcard under a high-level domain risky in a policy?
Every domain that matches the expression is implicitly trusted and can interact two ways with your server. That includes hosts an attacker can register, take over or abuse beneath that domain.
Which two mitigations does MITRE give that apply to every policy type?
Define a restrictive policy, and avoid wildcards in it. Both are attack surface reduction measures.
Does removing Flash from your stack remove the risk?
No. The same trust mistake applies to Content Security Policies and cross-origin headers. The old plugin CVEs are examples of the pattern, not the only form of it.
