Security and privacy

X-Permitted-Cross-Domain-Policies HTTP Header

Describes a response policy for legacy cross-domain policy-file handling by compatible clients.

Applicability

This field applies to HTTP responses.

Syntax

X-Permitted-Cross-Domain-Policies: none | master-only | by-content-type | by-ftp-filename | all

Examples

X-Permitted-Cross-Domain-Policies: none

Common use cases

  • Disable legacy Adobe cross-domain policy discovery on a host that does not require it.
  • Constrain an unavoidable legacy integration to an explicitly selected policy mode.

Common mistakes

  • Assuming the field controls modern browser CORS or iframe embedding.
  • Adding none while leaving a legacy integration dependent on a crossdomain.xml policy file.

Security considerations

Disabling unused legacy policy mechanisms reduces unexpected data access paths, but modern browser access still depends on CORS and other current controls.

Use the Security Headers Checker to evaluate supported browser-facing protections on a public website.

Detailed guidance

Meaning and behavior

X-Permitted-Cross-Domain-Policies is a non-standard compatibility header associated with legacy Adobe products and their cross-domain policy-file mechanism. A value of none instructs participating clients not to grant access through those policy files. Other historical values allow specific discovery or policy locations, with all being the broadest. The field arose before modern web CORS and is not interpreted as a CORS response header by current browser Fetch implementations.

Its relevance depends on the software consuming the response. Many modern applications have no Adobe client requirement and can use none as defense in depth, especially when legacy policy files might remain on a shared host. However, the field does not delete crossdomain.xml, cannot repair an overly permissive legacy policy by itself in every client, and does not affect normal JavaScript origin checks, framing, or server authorization. Behavior is implementation-specific and support is concentrated in legacy technology.

Implementation notes

Search the web root, storage buckets, and historical deployment artifacts for crossdomain.xml and related policy files. Confirm with application owners that no supported client depends on them. If the mechanism is unused, remove the files and emit none consistently. If a legacy dependency remains, document the exact client and choose the narrowest compatible value after testing. Review modern CORS separately because its headers and threat model are different. Treat scanner detection as evidence of the response value only; it cannot establish which obsolete clients still operate in a user’s environment.

Sources