I'm using nginx as a reverse proxy for my website.
I want to be able to open my website in an iFrame from a chrome extension new tab html file.
For this, I need my nginx to set X-Frame-Options to allow all domains.
According to this answer, all domains is the default state if you don't set X-Frame-Options.
My /etc/nginx/nginx.conf doesn't have the X-Frame-Options set anywhere.
Yet when I check my website response header using Postman, it shows me X-Frame-Options = SAMEORIGIN.
How can I remove this setting and load my website in an iFrame in the chrome new-tab .html file?
Solved it by changing proxy_hide_header values in /etc/nginx/sites-available/default file like so:
proxy_hide_header X-Frame-Options;
Needed to restart nginx as well as use pm2 to restart my nodejs server (for some reason, it didn't work till I made a small change to my server and restarted it).
add_header X-Frame-Options ""; did the trick for me in nginx 1.12.
Found this header in /etc/nginx/snippets/ssl-params.conf
Just needed to comment out the line:
# add_header X-Frame-Options DENY;
I found this header option in the file /etc/nginx/templates/default.conf.
add_header X-Frame-Options "SAMEORIGIN" always;
default.conf file is mentioned in my main nginx.conf file.
maybe you can try adding this in your nginx config
add_header X-Frame-Options "" always;
it works for me
Related
I have an nginx conf file containing some generic lines that I deploy on several websites. Among those lines I have this:
add_header X-Frame-Options "SAMEORIGIN";
For certain websites I want to deploy some custom lines. For example there are a few websites for which I want to deploy the following because I want to allow them to be loaded in some iframes:
add_header X-Frame-Options "";
So, those websites conf files end-up containing something like this:
# some generic settings
add_header X-Frame-Options "SAMEORIGIN";
...
# some custom settings
add_header X-Frame-Options "";
...
The problem is that the second add_header X-Frame-Options doesn't override the first.
I also tried to switch the settings and I put the custom ones first and then the generic ones. So the conf file looked like this:
# some custom settings
add_header X-Frame-Options "";
...
# some generic settings
add_header X-Frame-Options "SAMEORIGIN";
...
But again, the setting for X-Frame-Options was "SAMEORIGIN" and not "".
My question is: is there any possibility to override that X-Frame-Options add_header setting once it is set?
I'm running nginx 1.20 on a Ubuntu 18.
You can override it by setting Content-Security-Policy frame-ancestors directive. For all but legacy browsers, this will override X-Frame-Options. Try
Content-Security-Policy: frame-ancestors 'self' *;
You might not need 'self' (equals to XFO SAMEORIGIN), you can test without it.
I'm trying to figure out how to properly get CORS to work on all the images for our site - so that we can cache them using WorkBox for PWA that I'm building.
Our current setup is as follows -
I've my main site running on https://www.MyAwesomeSite.com and I've configured AWS Cloudfront to serve all our static assets (js,css and images) through URL https://data.MyAwesomeSite.com/.
My PWA is almost ready - except that the opaque responses (all images from Cloudfront) are blowing the cache size as expected. That is while the actual cache size is ~200KB - Chrome reports it to be around 300 - 400 MB.
While investigating the issue, I found out that Workbox may sometime Cache the Opaque responses which causes the Cache size issue.
After reading multiple posts and articles about CORS - I'm still not sure if I need to enable CORS on NGINX running on my server OR configure it on Cloudfront.
My First Approach:
I tried enabling CORS on my NGINX server by following the guide on:https://enable-cors.org/server_nginx.html . However, using the code as-is resulted into entire site showing 404 error.
In order to investigate this new issue, I found out that if blocks inside location are not reliable and are not recommended. I tried using maps function, but it did not work. My final approach to enabling CORS on my NGIX is this -
server {
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 http2 ssl; # managed by Certbot
root /path/to/my/files;
server_name www.MyAwesomeSite.com;
index index.php index.html index.htm index.nginx-debian.html;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
client_max_body_size 32M;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
# Rest of the configuration
While I'm not sure if this approach is correct - and whether it actually is the right way to do it; I do see the new headers in the regular GET requests for views being loaded from my server
My Second Approach
I then tried setting up CORS on my Cloudfront with the help of AWS Tech Support and it seems to be working as expected.
Then in order to tackle my original problem, I followed Google's recommendation to add crossorigin="anonymous" to all the image tags on my site.
But this leads to a new problem!
With crossorigin="anonymous added to all the images; I found out that Chrome would randomly vanish images stating No "Access-Control-Allow-Origin` headers were present on the response.
My main problems are as follows -
None of my images are being loaded via XHR requests. Do I still need CORS; and if I do - should I enable it on my NGINX or Cloudfront?
How do I ensure caching of image assets for my PWA without really blowing up the cache?
Am I missing out on anything important?
I'd really be thankful to anyone who helps me with this issue. I'm trying to figure this out since last 72 hours without any success.
The origin you're accessing from a different origin needs to enable cross-origin requests.
That is, your CloudFront config for data.myawesomesite.com needs to have the appropriate Access-Control-Allow-Origin headers, and related headers if necessary, to allow requests from sites loaded from www.myawesomesite.com if you expect to read that data in script.
I need to add the below X-Frame options in the nginx CF.
add_header X-Frame-Options "SAMEORIGIN";
I am using Cloud Foundry Staticfile buildpacks.
If I edit nginx.conf directly, it is getting removed whenever I deploy my application. So it is recommended to added through Staticfile buildpack.
But I don't know the exact value for the x-frame options.
Reference: https://docs.cloudfoundry.org/buildpacks/staticfile/index.html
Correct, you do not want to edit the config file directly. Your change will disappear the next time your app is restarted, restaged, recreated, crashes or even the next time the platform moves the app due to maintenance.
If you follow the instructions for adding custom Nginx configuration, you can put the configuration into a snippet & the Nginx configuration generated by the Staticfile buildpack will automatically read your config snippet.
Hope that helps!
Nginx.conf file Enable X-Frame-Options
location ~* \.(?:html)$ {
try_files $uri =404;
add_header Cache-Control 'no-cache, no-store, must-revalidate, max-age=0';
add_header X-Frame-Options 'SAMEORIGIN';
add_header X-Frame-Options 'DENY';
add_header Content-Security-Policy "frame-ancestors 'self';";
expires 0;
}
I am trying to add "add_header" to nginx but the reload is failing:
add_header
add_header Allow "GET, POST, HEAD" always;
When I run nginx -t, it points to this line mentioning I am passing too many parameters. Any idea what I am doing wrong?
url for add_header:
http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
You have an old nginx.
always flag was added in nginx 1.7.5
I want to add a custom header for the response received from the server behind nginx.
While add_header works for nginx-processed responses, it does nothing when the proxy_pass is used.
add_header works as well with proxy_pass as without. I just today set up a configuration where I've used exactly that directive. I have to admit though that I've struggled as well setting this up without exactly recalling the reason, though.
Right now I have a working configuration and it contains the following (among others):
server {
server_name .myserver.com
location / {
proxy_pass http://mybackend;
add_header X-Upstream $upstream_addr;
}
}
Before nginx 1.7.5 add_header worked only on successful responses, in contrast to the HttpHeadersMoreModule mentioned by Sebastian Goodman in his answer.
Since nginx 1.7.5 you can use the keyword always to include custom headers even in error responses. For example:
add_header X-Upstream $upstream_addr always;
Limitation: You cannot override the server header value using add_header.
Hide response header and then add a new custom header value
Adding a header with add_header works fine with proxy pass, but if there is an existing header value in the response it will stack the values.
If you want to set or replace a header value (for example replace the Access-Control-Allow-Origin header to match your client for allowing cross origin resource sharing) then you can do as follows:
# 1. hide the Access-Control-Allow-Origin from the server response
proxy_hide_header Access-Control-Allow-Origin;
# 2. add a new custom header that allows all * origins instead
add_header Access-Control-Allow-Origin *;
So proxy_hide_header combined with add_header gives you the power to set/replace response header values.
Similar answer can be found here on ServerFault
UPDATE:
Note: proxy_set_header is for setting request headers before the request is sent further, not for setting response headers (these configuration attributes for headers can be a bit confusing).
As oliver writes:
add_header works as well with proxy_pass as without.
However, as Shane writes, as of Nginx 1.7.5, you must pass always in order to get add_header to work for error responses, like so:
add_header X-Upstream $upstream_addr always;
There is a module called HttpHeadersMoreModule that gives you more control over headers. It does not come with Nginx and requires additional installation. With it, you can do something like this:
location ... {
more_set_headers "Server: my_server";
}
That will "set the Server output header to the custom value for any status code and any content type". It will replace headers that are already set or add them if unset.
You could try this solution :
In your location block when you use proxy_pass do something like this:
location ... {
add_header yourHeaderName yourValue;
proxy_pass xxxx://xxx_my_proxy_addr_xxx;
# Now use this solution:
proxy_ignore_headers yourHeaderName // but set by proxy
# Or if above didn't work maybe this:
proxy_hide_header yourHeaderName // but set by proxy
}
I'm not sure would it be exactly what you need but try some manipulation of this method and maybe result will fit your problem.
Also you can use this combination:
proxy_hide_header headerSetByProxy;
set $sent_http_header_set_by_proxy yourValue;