What I tried to do is to embed an iframe into a website and was faced with Content Security Policy.
I know this question was asked before, but I couldn’t find any working solution.
Error message:
Content security policy: 'x-frame-options' will affect because of 'frame-ancestors' directive.
What I tried so far, using the Apache module “mod_headers”:
Header unset X-Frame-Options Header unset Content-Security-Policy
Header always set Content-Security-Policy "frame-ancestors 'self';"
Header always set X-Frame-Options "SAMEORIGIN"
Header always setX-Frame-Options "ALLOW-FROM https://mydomain”
Any idea to get iframes embed, though Content security policy?
I have my virtual host machine on Apache2
I write Headers in site config:
Header set X-Frame-Options SAMEORIGIN
Header append X-Frame-Options "ALLOW-FROM *.yaad.net"
Header set Content-Security-Policy "child-src 'self' *.yaad.net; frame-ancestors *.yaad.net"
But still I get a bug in the browser.Error in DevTools
I don't understand how I can escaped from this error! I already read this article
What about I forgot ar forgot add?
It can be closed! I found a solution - this error concern on the service than provides me service - it send Headers to me only on exact domain name.
Thank all, for reading.
My first question. Just for reference, I support middleware and am not a developer. I’m trying to get the – Header always set X-content-type-options nosniff - working in the IHS httpd.conf file. The issue is - without the nosniff argument the page displays correctly. However when I add the header a blank page is displayed.
Below are some of the response header values. The content-length is non-empty and the return code is 200 so the content is there.
I believe the nosniff header is doing it’s job in that the content-type is text/html however the application server is returning test/javascript content (see below – Extract from the response), therefore it doesn’t display the page?
The Response header sets the following:
x-Content-Type-Options nosniff
x-Frame-Options DENY
content-type: text/html; type=SSA; charset=UTF-8
content-length: 20000
Extract from the response:
script type="text/javascript"
src="/ab24/contenthandler/!xx/q/blahblah....."/script
I don’t believe it matters where I locate the header as I’ve tried it in both the ‘Main’ server section as well as the section as I can see the header being set either way.
I believe the correct solution would be to have the back end application server change its code to respond with the content-type header set to ‘text/javascript’? However since I don’t have access to the code I’m trying to figure out if there is a way I can handle it in the httpd.conf file?
What I’ve tried thus far is since the config file has the TypesConfig conf/mimes.type and the mod_mime.so module loaded I noticed there wasn’t a text/javascript entry in the file so I added it, restarted IHS but no luck, still displays a blank page :(. Does anyone have any ideas if this could be handled somehow in the configuration file via some other directive(s), etc, or is the only way with a new code deploy?
I did look at many of the other questions related to x-content-type-options but couldn’t find an answer to my question.
i'm tried to enable X-FRAME only my spasific VH
on httpd-default.conf
i set the line:
Header always append X-Frame-Options SAMEORIGIN
on my website that i need to enable X-FRAME from specific Source:
Header always append X-Frame-Options "ALLOW-FROM https://sites.com"
my main idea it's to block by default X-FRAME
using apache 2.4
thanks
I had a problem using Header always append... (sometimes doesn't works) so I changed to:
Header set X-Frame-Options "ALLOW-FROM https://sites.com"
and it works!
Only remember than Chrome doesn't have support for ALLOW-FROM so it will be ignored and always can pass.
PD: It´s recomended to avoid the use of X-Frame-Options and change to Content Security Policy using frame-src: 'src' https://sites.com 'etc';
I have a website where virtual hosts are defined in /etc/apache2/sites-enabled/ with a header being set with the always option like this:
Header always set X-Frame-Options DENY
If I now set the same header using .htaccess in the web site's root folder, but without always then the header is returned twice in the server's response.
The setting in .htaccess (amongst others):
Header set X-Frame-Options DENY
The server's response:
HTTP/1.1 200 OK
Date: Mon, 02 May 2016 16:02:29 GMT
Server: Apache/2.4.10 (Debian)
X-Frame-Options: DENY
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Last-Modified: Mon, 02 May 2016 15:03:42 GMT
Accept-Ranges: bytes
Content-Length: 0
X-Frame-Options: DENY
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
The Apache docs say that without the always option the default value of onsuccess is used. But they also say that "... the default value of onsuccess does not limit an action to responses with a 2xx status code..." (http://httpd.apache.org/docs/current/en/mod/mod_headers.html#header).
But if I don't add always, then error pages like 301s and 404s will not have the header set. On the other hand, if I do add always then the headers might be set twice if I do use the default value (i.e. onsuccess) in .htaccess. As the docs state: "repeating this directive with both conditions makes sense in some scenarios because always is not a superset of onsuccess with respect to existing headers". Setting headers twice is not always valid for an HTTP response, see https://stackoverflow.com/a/4371395/641481. So I want to avoid it, naturally.
My question now is: When exactly should I use onsuccess (i.e. the default value) and when always? I must admit that even after reading through the Apache docs a couple of times I do not exactly understand this. Pragmatically it seems that always using always leads to the correct/expected behaviour.
I also do not understand why Apache writes the header twice if it is set in always and onsuccess. It seems wrong to me, but there must be a good reason for this, since I assume the Apache-devs know a lot more than I do about HTTP ;-)
This is only a partial answer since it does not cover the onsuccess attribute. It is based on experiences using apache 2.4.7 running on an Ubuntu 14 os. Hope it helps you along.
The pure set parameter, without attributes, to the Header directive overwrites any always attribute by forcing the argument to Header set to be the only one delivered. If the same directive appears in a directory, i.e. file system based .htaccess file it has precedence over the same directive noted in a virtual host definition file related to that directory. If the attribute always is noted additionaly, it has the effect that any, equal or different, notation of the same directive is added to the server answer instead of overwriting/replacing it.
Probably the onsuccess attribute, which i unfortunately do not have the time to explore now, may be handled similar as the always attribute.
We use Adobe Experience Manager with a Dispatcher [caching] module for our Apache webserver. Adobe recently changed the code below. Essentially I believe you may need to use the "expr=" syntax to make sure the value is not already set. That should eliminate the duplicates.
Here's the reference code from Adobe:
Original Config: Header always append X-Frame-Options SAMEORIGIN
New Config: Header merge X-Frame-Options SAMEORIGIN "expr=%{resp:X-Frame-Options}!='SAMEORIGIN'"
When I inquired, Adobe gave me the following reasons. Thanks Adobe.
Explanation:
Using "merge" instead of "append" prevents the entry's value from from being added to the header more than once.
expr=expression: The directive is applied if and only if expression evaluates to true. Details of expression syntax and evaluation are documented in the ap_expr documentation. The "expr" is looking in the response headers from the server (Publisher Application Server) to make sure that it does not include SAMEORIGIN. This ensures that SAMEORGIN is not duplicated in the response header sent back to the request client.
It's required because testing has found that when AEM included this header Apache would duplicate the SAMEORIGIN value even with the merge option. Apache is capable of proper merge when it sources the header from itself, but because the first header was set by AEM outside of the Apache instance is when it gets weird (and requires the extra expression).
It also appears that they do not use "always" with the merge+expr syntax. Perhaps to also work around an Apache weirdness.
PS... remember to change "SAMEORIGIN" for "DENY" in your case.