OWASP says the X-Permitted-Cross-Domain-Policies security header gives web clients "permission to handle data across domains". It specifically states that Adobe's Flash Player and Acrobat PDF Reader use this header and that other web clients could possibly benefit from the header too. The reference links provided reinforce the benefit to Adobe products but don't give any other situations where this security header is beneficial.

I can't find any benefit to this header unless I'm using Flash or PDF. So in that light, does the X-Permitted-Cross-Domain-Policies header have any benefit for my website if I'm not using Adobe products?


You have it the wrong way round. Much like Access-Control-Allow-Origin the purpose is to allow other systems (in this case specifically web-hosted Flash and PDF content) to access your domain. The "remote domain" is you, the "source domain" is who we're defending against.

When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

By default, all cross-domain requests will be blocked by Adobe's software, the same as browsers block cross-domain XMLHttpRequest.

An unwanted policy file may find its way onto your site, either by accident or malice. The purpose of adding X-Permitted-Cross-Domain-Policies in this case is to override it, so that the client still blocks unwanted requests.

Microsoft Silverlight uses a different policy file format, but it may also still use this header.

If you allow people to upload files, or are concerned about intruders using a different flaw to get files onto your server AND the content on your domain should not be accessed via other websites possibly trying to impersonate you, then yes X-Permitted-Cross-Domain-Policies will provide a security benefit. The attack is less relevant these days, as any user of modern software first needs to be tricked into allowing Flash or active PDF content.

If your website is just a regular website with nothing that requires a login to access, then you don't need it.

  • Great answer! A minor nitpick for clarity: It's not enough to just use the header, you have to set it to none to get any benefits. – Anders Jul 16 '19 at 17:01
  • @Anders only if you want it to be none. There are other options you may want, that you don't want to be overridden. – OrangeDog Jul 16 '19 at 17:01

If your project is not using Flash and pdf, there is no need for that header.

References :



  • 5
    Your first link doesn't reference the header. The second link says this, 'The authors of Adobe Flash and PDF documents can embed content from websites in their productions. ... [Y]ou can regulate which of your content... these authors can use in their files." And, "When you don’t want to allow content producers to embed your work in their content, ensure you have no crossdomain.xml files within your website’s directory structure. You should also send the [X-Permitted-Cross-Domain-Policies] header with each response from your web-server. Isn't this the opposite of what you said? – Taul Oct 9 '17 at 17:07
  • 2
    This answer is wrong. – OrangeDog Jul 16 '19 at 16:05

Yes agreed to that, this header is made for flash players and PDF not necessarily Adobe products other flash players will need it.If you are not using your site for distributing flash player or pdf files then you do not need this header.

  • Do you have any resources that back up your answer? – Taul Jul 26 '17 at 23:33
  • This answer is wrong. – OrangeDog Jul 16 '19 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.