I want to ask how to set X-Frame-Options and Content Security Policy on netlify. As I have static website and its deployment server is netlify and I don't have any configuration file(netlify.toml). So, where can I set X-frame-Options and Content Security Policy.
Save a plain text file called _headers to the publish directory of your site (see details and syntax). For instance:
# a path:
/templates/index.html
# headers for that path:
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';
# any other paths:
/*
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Also you can use specific CSP packages for Netlify. Generally they do the same - add headers into _headers file, but some of they do calculate hashes for scripts.
Related
I added the
<meta http-equiv="X-Frame-Options" content="deny">
in header.tpl file ,but it not working and throws an error.
X-Frame-Options may only be set via an HTTP header sent along with a document. It may not be set inside .
And I also added the
Header always append X-Frame-Options SAMEORIGIN
line in .htaccess file. But this is also not working.
Then how can I prevent Clickjacking on my Website?
For references : Clickjacking Defense Cheat Sheet | OWASP and X-Frame-Options - HTTP
I suggest you to edit the .htaccess in your PrestaShop root folder installation and, just before the lines identified by "# ~~start~~ Do not remove..." add the following block:
# Extra Security Headers
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'unsafe-inline' 'unsafe-eval' 'self' *.googleapis.com *.gstatic.com;"
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
</IfModule>
This will provide protection against:
clickjacking - content sniffing - XSS attacks
I don´t know how to solve and issue with Problem Content Security Policy.
I have apache2 running debian on a raspberry.
I one on my web im calling to this script:
https://sis.redsys.es/sis/NC/redsys.js
And Only works on IE11 :(
On chrome and Firefox dont work.
I add this lines to security.conf on apache
Header set X-Frame-Options: "sameorigin"
Header append X-Frame-Options "ALLOW-FROM https://sis.redsys.es/sis/NC/redsys.js"
Header append X-Frame-Options "ALLOW-FROM https://sis.redsys.es*"
Header append X-Frame-Options "ALLOW-FROM https://www.redsys.es/"
#Header set Content-Security-Policy: "default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'"
But it still not working.
I getthis from Chrome:
Refused to display 'https://sis.redsys.es/sis/getInputNC?buttonValue=5061676172&styleButton=&styleBody=&styleBox=&styleBoxText=&frame=inSite&fuc=323233313038383533&terminal=31&order=303030304153' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors https://www.bancsabadell.com https://www.google.es".
This gets A+ score from observatory.mozilla.org :
Header set Content-Security-Policy "default-src 'none'; img-src 'self' data:; media-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' data:; font-src 'self' data:; object-src 'self'; base-uri 'self'; connect-src 'self'; form-action 'self' sis.redsys.es; frame-ancestors 'self'"
If your website needs to add 'unsafe-inline' to script-src then it will drop scoring to B.
I have been looking at this for some time now, and what it basically says is that www.redsys.es doesn't allow you to use their content in an iFrame.
The Guardian is (in my understanding) using a pretty relaxed Content-Security Policy:
default-src https:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'; img-src https: data: blob:; media-src https: data: blob:; font-src https: data:; connect-src https: wss:
Are there any advantages of using such a CSP as opposed to using none at all.
Security wise, a relaxed one is still better than none.
In the above Guardian example, it disallows all http resources to be embedded.
The headers are not recognized by mozilla observatory. Any ideas?
add_header Content-Security-Policy: "frame-ancestors 'none'";
add_header X-Frame-Options: DENY;
Lose the : for a start.
It may not be necessary but I escape my ' instead of mixing and matching " and '.
Mine looks like this and works:
add_header Content-Security-Policy 'default-src \'self\' *.example.com; report-uri ....';
We are moving our Federal government website to https-only. We have received complaints from sites we link to that our referrers have disappeared, when those sites use only http. This is because https->http downgrade, by default, hides the referrer.
We are trying to use the HTTP request header Referrer-Policy: origin-when-cross-origin, but it doesn't seem to work. However, putting <meta name='referrer' content='origin-when-cross-origin'> indeed provides the correct behavior for most browsers.
We are setting the header:
<pre>
$ curl -sI https://www.ncbi.nlm.nih.gov/corecgi/tests/testref.cgi
HTTP/1.1 200 OK
Date: Fri, 04 Nov 2016 20:53:38 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: upgrade-insecure-requests
Referrer-Policy: origin-when-cross-origin
Content-Security-Policy-Report-Only: default-src https:; script-src https: 'unsafe-inline' 'unsafe-eval'; font-src https: data:; img-src https: data:; style-src https: 'unsafe-inline'; report-uri https://www.ncbi.nlm.nih.gov/corecgi/csp/csp.cgi
Referrer-Policy: origin-when-cross-origin
Access-Control-Allow-Methods: POST, GET, PUT, OPTIONS, PATCH, DELETE
Access-Control-Allow-Origin:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-Accept-Charset,X-Accept,Content-Type,X-Requested-With,NCBI-SID,NCBI-PHID
Content-Type: text/html
Vary: Accept-Encoding
X-UA-Compatible: IE=Edge
X-XSS-Protection: 1; mode=block
</pre>
But that header doesn't work:
Try this: https://www.ncbi.nlm.nih.gov/corecgi/tests/testref.cgi
Notice that the https->http downgrade link sends a blank header
Yet it the <meta> element gives the desired behavior:
https://www.ncbi.nlm.nih.gov/corecgi/tests/testref.cgi?meta=true
Has anyone else had, and fixed, this problem?
It looks like Chrome is about to, but doesn't quite yet, support the Referrer-Policy header:
https://bugs.chromium.org/p/chromium/issues/detail?id=619228
https://www.chromestatus.com/feature/5639972996513792
It will be available in Chrome 56 stable. It's been behind a flag since Chrome 53, so you can run Chrome with --enable-experimental-web-platform-features to try it out there.
Referrer-Policy header support will ship in Firefox 50:
https://developer.mozilla.org/en-US/Firefox/Releases/50#HTTP