I have a W2016 server with IIS 10 running on it and I am having problems implementing policy (used to apache) on how to add in the correct headers for Content Security Policy/CORS/X-frame. It seems that IIS has gone out of its way already to add SAMEORIGIN by default, as I don't see it listed anywhere (the server or the site in question).

So what is the best way to ensure that mysite.example.com can be iframed into any site and also if I want to lock down iframing can I have a policy to allow iframing on the wildcard of the root - so *.example.com.

1 Answer 1


The X-Frame-Options header is used to control whether your site can be included in frames on other sites - SAMEORIGIN will allow you to host your site in an iFrame, whilst DENY will block everyone, including you.

The Content Security Policy then controls what sites you can include in various elements of your site (images, frames, scripts, etc.).

The CSP can be set either in the metadata or via the headers sent in the response - note however that multiple directives make the policy more restrictive, not less.

If you only have a limited set of sources you are serving frames from, you can add all the domains to the policy, however if there can be arbitrary domains you may be better just using the scheme directive:

Only allow frames from https://example.com/ requests to http://example.com or https://www.example.com will be blocked:

Content-Security-Policy: frame-src https://example.com/

Allow frames from any secure site:

Content-Security-Policy: frame-src https:

Running your site under IIS, even with PHP, you should still have a web.config in the root of your site - the following section can be added (or adjusted) to set these headers on all outbound requests:

        <!-- Remove the default X-Frame-Options header -->
        <remove name="X-Frame-Options" />
        <!-- Add CSP header with frame and default sources allowing HTTP and HTTPS, and inline scripts -->
        <add name="Content-Security-Policy" value="frame-src https: http; default-src https: http: 'unsafe-inline' 'unsafe-eval'" />
        <!-- Set a CORS header to allow requests from anywhere -->
        <add name="Access-Control-Allow-Origin" value="*" />

Note however the following constraints, many of which are applied by the browsers directly:

  1. If your site is served over HTTPS, the frame contents will be blocked (regardless of the CSP) if it's requested over HTTP (you might be able to use the upgrade-insecure-requests directive to get around that if the requested site also responds on HTTPS).
  2. If the requested site sends its own CORS headers, and they don't include your domain (or *), the browser will block those requests
  3. If the requested site sends an X-Frame-Options header of SAMEORIGIN or DENY the browser will block those requests.
  • TY - will try this out tonight. It is very frustrating understanding how everything works yet implementation seems so "goofy". The fact that IIS is injecting sameorigin (I don't think I have any mods doing this) and the fact that there are rules like having two statements making things more restrictive, not doing what the statement says... this is just a mess. You would think with the browser updates locking these things down more there would be better documentation on requirements.
    – blankip
    Apr 26, 2021 at 17:47
  • Full documentation on CSP can be found here: developer.mozilla.org/en-US/docs/Web/HTTP/Headers/…. IIS tries to help developers to "fall into the pit of success" by being configured with relatively sensible, secure defaults these days. There may be other things also doing this (MVC5+ for example adds this by default and needs to turned off a different way) such as mods, etc. so do check there - but that web.config rule should help remove it. Apr 26, 2021 at 18:27

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.