There's a crossdomain.xml on your server from 2014. What does it still allow?

Flash is dead. Silverlight is dead. But the files they used to read are still sitting in plenty of web roots, because nobody ever deleted them. Type /crossdomain.xml after a domain and you'll find them more often than you'd think: a small XML file that once told the Flash Player which foreign origins were allowed to make credentialed reads against the server.

The reason it matters that the file outlived the plugin is the line a lot of these files contain. <allow-access-from domain="*"/> means any origin. It was a convenient default when someone set it up to make a Flash widget work, and it's been granting "anyone can read across origins" ever since, to whatever still honors the file.

Two files, one mistake

There are two of these legacy policy files, and they're the Flash and Silverlight versions of the same idea.

/crossdomain.xml is the Flash one. The dangerous shape is <allow-access-from domain="*"> inside a <cross-domain-policy> root. /clientaccesspolicy.xml is the Silverlight one, with <domain uri="*"> inside an <access-policy> root. Either, with the wildcard, says the same thing: a script loaded on any other website may make cross-origin, credentialed requests to this host and read the responses.

That's the protection the browser's same-origin policy and CORS exist to enforce, undone by a static file. The catch in 2026 is that you can't just say "but Flash is gone, so nothing reads it." The browser plugins are gone, but the files are still parsed by some HTTP client libraries, SDKs, and legacy tooling that were written to respect a cross-domain policy and never updated. The blast radius is smaller than it was a decade ago. It is not zero, and there is no upside to leaving a wildcard grant published.

Why a check here doesn't cry wolf

The danger isn't the file existing. A crossdomain.xml that names specific, trusted origins is doing its job, and an absent file is fine. The danger is the wildcard, and a finding has to be precise about that or it becomes the kind of false alarm that gets a scanner ignored.

So the bar is three signals at once. The server has to return a 200 for the path, not a soft-404 that answers everything with a friendly HTML page. The body has to have the real policy root element, <cross-domain-policy> or <access-policy>, so a catch-all page that happens to return 200 can't trip it. And it has to contain a literal domain="*" or uri="*" grant. A restrictive, named-domain policy fires nothing. An absent file fires nothing. Only a genuine, published, wide-open grant counts.

It's a medium-severity finding. Lower than a leaked secret, because the set of clients that still read the file is shrinking, but real, because a wildcard cross-origin grant is a misconfiguration with no legitimate reason to exist on a modern site.

The fix is a delete key

If you don't run a Flash or Silverlight client (and you don't), the fix is to remove the file. There's nothing to migrate. If for some reason a legacy integration genuinely needs a cross-domain policy, replace the wildcard with the specific origins that need access.

# /crossdomain.xml
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

Whether a wildcard policy file is still being served is something a stranger checks by requesting two fixed paths, which is exactly how SurfaceCheckr checks it: a plain GET of /crossdomain.xml and /clientaccesspolicy.xml, confirming the genuine policy root element and a literal * grant before it says a word. It reads the file the way an old SDK would and stops there. No login, no payload, just a read of whether a decade-old convenience is still handing your origin away.

The modern version of "which origins can read my responses" is CORS, covered in the CORS misconfiguration article, and the wider question of what an old deployment left behind is in the files you forgot you deployed.