Cross-Domain Policies: crossdomain.xml and clientaccesspolicy.xml Risks

Two small XML files sitting in your web root could be granting any website on the internet full access to your users' authenticated sessions. The crossdomain.xml and clientaccesspolicy.xml files were designed to enable legitimate cross-domain communication for Flash and Silverlight applications, but overly permissive configurations remain a serious security risk – even now that those technologies are deprecated.

This article explains what these files do, why they still matter, how attackers exploit them, and how to test and fix your configuration.

What Are Cross-Domain Policy Files?

Browsers enforce the Same-Origin Policy (SOP) to prevent one website from reading data from another. However, technologies like Adobe Flash and Microsoft Silverlight implemented their own cross-origin models that predated CORS. These technologies relied on XML policy files served from the target domain to determine which external domains could make cross-origin requests.

crossdomain.xml (Adobe Flash)

Flash Player checked for /crossdomain.xml on the target domain before allowing a SWF file from another domain to read data. A permissive example:

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

The wildcard * grants every domain on the internet permission to make authenticated cross-origin requests to your site via Flash. This means any website could load a hidden SWF that reads your users' account pages, API responses, CSRF tokens, and session data.

clientaccesspolicy.xml (Microsoft Silverlight)

Silverlight used a similar mechanism with /clientaccesspolicy.xml:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Silverlight also fell back to reading crossdomain.xml if its own policy file was absent, so a permissive Flash policy affected Silverlight as well.

Why These Files Still Matter in 2026

Flash reached end-of-life in December 2020 and Silverlight in October 2021. Modern browsers no longer support either plugin. So why should you care?

• Legacy browser usage: in some industries (healthcare, manufacturing, government), legacy systems with outdated browsers that still support Flash or Silverlight remain in use.
• Vulnerability scanners flag them: PCI DSS compliance scans, penetration tests, and automated security scanners will flag permissive cross-domain policies as vulnerabilities. Leaving them in place wastes time on every audit.
• Indicator of neglected security posture: if a site still has a wildcard crossdomain.xml, what else has been neglected? Auditors and attackers both use these files as a signal to investigate further.
• Future technologies: while unlikely, future browser plugins or embedded runtimes could potentially honor these policy files.

How Attackers Exploit Permissive Policies

In the era of Flash, the attack was straightforward:

1. Attacker hosts a malicious SWF file on evil.com
2. Victim visits evil.com (via phishing, malvertising, or a compromised site)
3. The SWF makes an HTTP request to target.com/api/account – the victim's cookies for target.com are included automatically
4. Flash checks target.com/crossdomain.xml, finds allow-access-from domain="*", and permits the SWF to read the response
5. The SWF sends the response data (account details, CSRF tokens, etc.) back to evil.com

This is effectively a complete bypass of the Same-Origin Policy for any authenticated endpoint on the target domain. Combined with a CSRF token read, the attacker can perform any action the victim can.

Testing Your Configuration

Use our Cross-Domain Policy Test tool to instantly check whether your site serves either policy file and whether the configuration is permissive. The tool will:

• Fetch /crossdomain.xml and /clientaccesspolicy.xml
• Parse the policy and evaluate its permissiveness
• Flag wildcard domains, overly broad path grants, and insecure attributes
• Provide specific remediation steps

You can also check manually with curl:

curl -s https://example.com/crossdomain.xml
curl -s https://example.com/clientaccesspolicy.xml

If either returns a valid XML policy, evaluate whether it is still needed.

Remediation

Option 1: Remove the Files (Recommended)

If you no longer need Flash or Silverlight cross-domain access (and you almost certainly do not), delete both files entirely. The server should return a 404 for both URLs.

Option 2: Restrict to Specific Domains

If you have a legitimate need for a cross-domain policy (extremely rare in 2026), restrict it to only the specific domains that require access:

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="trusted-partner.com" secure="true" />
</cross-domain-policy>

Note the secure="true" attribute, which ensures the policy only applies to HTTPS requests.

Option 3: Serve a Restrictive Policy

Serve a policy file that explicitly denies all cross-domain access. This can prevent Silverlight's fallback behavior and makes your security posture explicit:

<?xml version="1.0"?>
<cross-domain-policy>
  <site-control permitted-cross-domain-policies="none" />
</cross-domain-policy>

Cross-Domain Policies and WordPress

WordPress itself does not create cross-domain policy files, but they can appear through:

• Hosting providers that add default configurations
• Plugins that create them for specific integrations (media players, payment gateways)
• Legacy deployments that were never cleaned up

Check for these files as part of your regular WordPress security hardening process. While you are auditing your WordPress installation, also scan for known plugin vulnerabilities and review your security headers configuration.

Relationship to CORS

Modern cross-origin access is controlled by CORS (Cross-Origin Resource Sharing) headers, which are enforced by the browser natively without any plugin. CORS is a much more granular and secure mechanism:

• CORS policies are set per-endpoint via HTTP headers, not globally via a single file
• Browsers enforce CORS natively – no plugin required
• Access-Control-Allow-Origin: * does not send credentials (cookies) by default, unlike Flash's wildcard which did include cookies

If you are implementing cross-origin access for a modern application, use CORS headers exclusively. Never create a crossdomain.xml as a workaround for CORS configuration issues.