Flash crossdomain.xml Bugs: Legacy Policy Files Still Expose Data
Flash is dead in mainstream browsers. Forgotten Flash policy files are not. I still request /crossdomain.xml during recon because old upload services, media hosts, appliances, and API gateways keep them around for clients nobody remembers.
Is every wildcard policy exploitable today? No. A finding needs a consumer that honors the policy or a backend ecosystem where the file remains security-relevant. Treat it as legacy attack surface, not an instant critical.
Read what the policy grants
A dangerous file often looks like:
<cross-domain-policy>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
allow-access-from controls which domains may read data. A wildcard grants any origin recognized by the Flash runtime. secure="false" may allow an insecure origin to reach an HTTPS target. The header rule widens what a cross-domain client may send, sometimes including application-specific authentication headers.
Also inspect site-control. It determines whether policy files below the root can grant permissions. A restrictive root can be undone by an overlooked policy in /uploads/crossdomain.xml when the master policy permits it.
Hunt the policy, then hunt its clients
Check root domains, API hosts, CDN aliases, old media and static subdomains, plus ports exposed by legacy services. Search archived JavaScript and public repositories for .swf, Security.loadPolicyFile, socket policy ports, and hard-coded API hosts.
Now ask what the trusted cross-domain request could read. Public images do not matter. Authenticated XML APIs, internal status endpoints, user documents, and endpoints using ambient cookies do.
Browsers no longer running Flash sharply reduce practical reach, yet desktop AIR applications, old kiosk deployments, enterprise wrappers, and bundled projectors may still execute the policy model. A program with such a supported client has a credible attack path. Without one, report the exposure conservatively as stale hardening unless you can demonstrate an active consumer.
A bounded proof
Use an account you own and a controlled client environment approved by scope. Host the requesting content on your own domain, call a benign authenticated endpoint, and show that its canary response becomes readable cross-domain. Record whether cookies or custom headers were sent.
Do not resurrect an ancient plugin on a daily-use machine. Run it in an isolated VM with no personal credentials. Old Flash runtimes carry their own vulnerabilities, and your test lab should not become the easiest target in the chain.
Severity without nostalgia
The policy file is a permission statement. Impact comes from the data and client that use it. A wildcard on an abandoned asset host is informational. A wildcard on an API still consumed by a supported AIR application, where session-bound records can be read, is a cross-origin data theft issue.
Fix by removing unused policy files, narrowing trusted domains and headers where a legacy client must remain, requiring modern token authorization that is not ambient, and migrating the client. Inventory subdirectory policies too. Deleting the root file while leaving a permissive alternate policy path can preserve the bug.
The best reports include the exact policy directives, evidence of an active client, one owned-account response, and an honest statement about prerequisites. Legacy does not mean harmless; it does mean you must prove who can still pull the trigger.