SSL & Security

Cross Domain Policy Checker

X-Permitted-Cross-Domain-Policies

Audit a site's cross-domain policy

We'll read the X-Permitted-Cross-Domain-Policies header, then fetch /crossdomain.xml and /clientaccesspolicy.xml from the origin root and parse every grant they contain.

Try:
adobe.com
wikipedia.org
github.com

Tool features

Complete cross-domain policy analysis with prioritised fixes
4 checks

The Header & The Files

Reads X-Permitted-Cross-Domain-Policies and fetches both policy files from the origin root

Every Grant Parsed

Each allow-access-from and header grant, with the origins it actually covers

Meta-Policy Resolution

Shows which of the three sources wins, so you see what a client really applies

Security Score

An overall score out of 100 with prioritised, specific fixes

What a cross-domain policy is & why it matters

How crossdomain.xml and the meta-policy header fit together

Long before Access-Control-Allow-Origin, browser plugins had their own way of asking permission to read another site's data: a file at /crossdomain.xml. If it said <allow-access-from domain="*"/>, any website could have Flash Player fetch this origin's pages with the visitor's cookies attached and read the response — the exact thing the same-origin policy exists to stop.

The X-Permitted-Cross-Domain-Policies header is the control on top of that: a meta-policy declaring which files on the host are even allowed to be policy files. Set to none, no file is honoured, so an XML file uploaded through an avatar form or written into a misconfigured storage bucket can never become a grant.

Flash reached end of life in December 2020 and Silverlight left support in October 2021, so the exposure is narrower than it was — but it has not closed. Adobe Acrobat and Reader still consult crossdomain.xml before letting a PDF fetch data across origins, and the missing header is a standing finding in PCI DSS and OWASP header reviews. A forgotten wildcard policy file is also a reliable marker of a web root nobody has audited in a decade.

This tool reads the header from the site itself, then fetches both policy files directly from the origin's root and parses every grant in them — because the header on your homepage does not disable a policy file that is still being served. The meta-policy that actually governs is the one attached to /crossdomain.xml.

X-Permitted-Cross-Domain-Policies
Response header declaring which files on this host may act as cross-domain policy files. "none" is the safe answer.
crossdomain.xml
The master policy file Flash and Adobe Acrobat read from the web root to decide which origins may read this one.
allow-access-from
One grant inside the policy file. domain="*" grants every website on the internet.
site-control
The element inside the policy file that sets the meta-policy, when no header does it.
clientaccesspolicy.xml
Silverlight's equivalent policy file, read independently of crossdomain.xml.

How to use this tool

Audit a site's cross-domain policy in four steps
1
Enter a domain or URL
Type a hostname or a full URL, e.g. example.com or https://example.com.
2
Run the check
Click Check Policy to read the response header and fetch /crossdomain.xml and /clientaccesspolicy.xml from the origin root.
3
Read the grants
See which origins each policy file grants access to, and which meta-policy a client actually applies after precedence is resolved.
4
Close the gap
Delete policy files nothing depends on, send X-Permitted-Cross-Domain-Policies: none, then re-check to confirm.

Related tools

Keep debugging with tools from the same suite
5 tools
Secure Header Checker
Check security headers like CSP, HSTS, X-Frame-Options, and more with security scoring
CORS Headers Checker
Check and analyze Cross-Origin Resource Sharing (CORS) headers for security configuration
OCSP Checker
Check SSL certificate revocation status using the Online Certificate Status Protocol (OCSP)
X-Frame Options Checker
Check X-Frame-Options header to prevent clickjacking attacks and iframe embedding
Cookie Security Checker
Audit every Set-Cookie header a site returns for the Secure, HttpOnly, SameSite, prefix, scope and expiry attributes

Frequently asked questions

Common questions about cross-domain policies
6 Q&A

It declares a meta-policy: which files on your host are allowed to act as cross-domain policy files for Adobe clients. Set to "none", no file is honoured — so an XML file that reaches your web root through an upload form or a misconfigured storage bucket can never grant another site access to your responses.

Less than it did, but yes. Adobe Acrobat and Reader still read crossdomain.xml before allowing a PDF to fetch data across origins, so a wildcard policy file is a live grant, not a historical one. The header is also an explicit requirement in PCI DSS and OWASP header reviews, which is why it appears on nearly every scan report.

none, on every response. The five defined values are none, master-only, by-content-type, by-ftp-filename and all. Use master-only only if you genuinely serve a /crossdomain.xml that a client depends on; never use all, which lets any file on the host act as a policy file.

Because lets any website have a plugin client request your pages with the visitor's cookies attached and read the response back. That bypasses the same-origin policy for authenticated content: session pages, account data, and CSRF tokens all become readable by the attacking site.

Delete it, unless something still depends on it. Narrowing the domain list shrinks the exposure; removing the file removes it. An empty policy file is harmless as written but is one edit — or one restored backup — away from granting something again.

Because precedence runs the other way. The meta-policy a client applies is the one served with the master policy file — the header on the /crossdomain.xml response, or the element inside it — falling back to the client default. The header on an ordinary page is what scanners read, but it does not switch off a policy file that is still being served.