It's important to note that after implementing HTTP Strict Transport Security (HSTS), you've basically dropped HTTP entirely (for all subdomains, too, if you set includeSubDomains), and it's practically impossible to revert that change once browsers have picked up on it, particularly when you've made it onto the preload lists. So tread carefully, and don't set any headers manually before understanding the implications.

Wasn't aware of Expect-CT yet, thanks.

True it doesn't permit HTTP access but setting up the headers correctly should allow a NEW browser access to connect and be automaticaly switched to HTTPS.

Great post dstiles. I use *versions* of these headers, except for CSP (possibly the most important one) because my host has trouble with it.

Expect-CT [scotthelme.co.uk] allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their Certificate Transparency (CT) policy.

Here's a couple tools for checking security headers:
[observatory.mozilla.org...]
[securityheaders.io...]

Also, Web Security Guidelines Wiki:
[wiki.mozilla.org...]

BTW - most all security certificate agencies are announcing their support for CT.

We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links:

[letsencrypt.org...]

Examples of how this would be done on Apache shared hosting via htaccess file:

Header set Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';"
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header set X-Robots-Tag "notranslate, noarchive"
Header set X-Frame-Options "deny"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer"
Header set Expect-CT "max-age=0; report-uri=https://example.com/ct/reportOnly"

Note: exact syntax would depend on server config

- - -

I use IIS web servers - I wish I didn't but too late!

In IIS...

Secure cookies: in Configuration Editor section system.web/httpcookies set
httpOnlyCookies true
requireSSL true
(and select Lock from right-hand menu)

The other headers are set in the HTTP Response Headers section of the IIS manager. These values can all be set either on individual sites or globally in the parent Server section (between Start Page and Application Pools in the left pane).

As far as I know, character case is unimportant but it probably is better to conform to the case as published.

I did set up some parameters globally on a 2012 server with mixed SSL and non-SSL sites. The latter seemed to ignore some settings and if a site was later converted to SSL they had to be re-entered correctly.

Public Key Pinning (HPKP)

Further to my original post Google, the originator of this, has declared it is dropping it because it's potentially dangerous to web sites. This was after a report by Scott Helme.

RE: HPKP

I read that concern so I avoided it.

Just a note about "SSL" used in the Title of this thread and in early posts. Most all servers have replaced SSL (Secure Sockets Layer) with TLS (Transport Layer Security) now.

TLS is an updated, more secure, version of SSL. The current version of TLS is version 1.2.

[tools.ietf.org...]

X-Xss-Protection has joined the dialogue a lot lately because of Advertisers running 3rd party scripts that have not been approved. This header stops the visitor's browser from getting caught by these scripts.

The header is designed to stop a page from loading when the browser detects cross-site scripting (XSS) attacks, and is part of the comprehensive security header protection all sites should be using.

[developer.mozilla.org...]

Header set X-XSS-Protection "1; mode=block"

I set up backup ads, for my Adsense slots. Rather frequently, some slot remain blank randomly. No Adsense ads, and "my" backup ads are not called either. So I was wondering if the mode=block could cause this issue. So I remove the mode parameters. Which means that the web browser is still sanitizing the content, but is not blocking its rendering, and bam, now, my backup ads page is called each time Adsense has no ads to display. So , I suspect that "sometimes" (not always?!) when Adsense is serving the backup ads page, it might use a script that web browser interpret as XSS attempts...

So my question is. If the mode parameter is not used, is it really more risky?

Yes, from my understanding the header needs to be complete.

You list the source of all 3rd party scripting in the CSP (Content-Security-Policy) header, seperate by commas.

[developers.google.com...]

I have to confess that I am bit confused with the CSP field, I studied and read a lot, I configured it the way I think it's fine, but I still worry I've been too restrictive.

Restrict as much as possible. Check your site in various browsers to see if ALL of your pages and files are accessible and check any forms you have to ensure they can be submitted.

You are trying to stop hackers dumping stuff directly or by man-in-the-middle interception into your site as it's seen by your visitors. If you can see your site in popular browsers then it's your visitors problem if they can't.

If you have third-party adverts or other content then add those sources specifically and explicitly to CSP. But remember people like me tend to run anti-third-party software such as uBlock anyway so may well not see it.

if you have third-party adverts or other content then add those sources specifically and explicitly to CSP.

Yes, and that's it my concerns. I don't know if there are specific things to add to the CSP, related to Adsense ads.

When I look at the console window, does Chrome (or Firefox) , is supposed to output information, when things are blocked because of CSP ? Because, when I visit my site, all seems to work, but sometimes, ads are not showing, blank-blank, whereas I set up backup ads. (my backup ads page is not even called when it happens). So I am wondering if it can be related to the Security headers, being badly configured, but the web dev console is not showing any message when it happens.

You have to add the source address of both google ads and your own. Learn how to concatenate domains such as google and your ad own server into a single CSP field. Make sure they are HTTPS ads not HTTP - not sure if the latter would work but it defeats the security aspect.

Check with the scott helme sites - he has a LOT of info on CSP etc. Also, Mozilla's security offerings. Both have test URLs to check your syntax etc.

As to browsers blocking your ads - yes, some will be set up that way; possibly at different levels depending on content. There are also switches in browsers that allow/disallow frames/iframes. And swtches to turn off media content (eg video). And, of course, pop-up blockers.

Browsers may also block content that does not have proper HSTS (Strict Transport Security). Or even Certificate Key Pinning - which is now deprecated in most cases.

And when it comes to browsers in Privacy mode or that reject cookies - another ballgame again.

I've added more fields to some of my sites in the past few months. The list below is selective according to site content. Add, modify, enable for your own situation.

Name: Content-Security-Policy
Value: default-src 'none'; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; img-src 'self'; script-src 'self' 'unsafe-inline'; upgrade-insecure-requests; block-all-mixed-content; object-src 'none';

In one case, to allow a form submission to a payment service, I have:
form-action 'self' https://example.com;

In another, to allow videos to play...
child-src 'self' https://player.example.com/video/;

Where you want browsers to display content within the browser instead of in a viewer (Safari seems very touchy about this):
plugin-types application/pdf;

Also check the other headers mentioned in the first post. Expect-CT could kill your site if the certificate isn't properly issued and appled, for example. X-Frame-Options is now replaced by the frames values in CSP. And make sure the cookies flags are correctly set.

Thank you dstiles

X-Frame-Options is now replaced by the frames values in CSP

Not really replaced. They overlap, but CSP gives much more control of whom is allowed to run any script. X-Frame is selective to just framing. I still use it to block remote framing/hijacking.

True. I also use it but my reason is: older user-agents may not recognise the CSP version, since it's newer.

That would be useful info... a breakdown of what browser & version supports what header fields, and not just these aforementioned security headers.

As for CSP:

Browser Support
Fortunately, support for the CSP header is widespread but there is one thing to watch out for, good old Internet Explorer. The Content-Security-Policy header is supported in the latest and greatest versions of Chrome, FireFox, Safari (OSX and iOS), Opera (but not Mini), the Android Browser and Chrome for Android. Internet Explorer, however, requires the X-Content-Security-Policy header instead. This means that if you want to have the most widespread support for your CSP header, you will need to issue it twice! I have to admit I'm not a great fan of that prospect but hopefully that will change in IE 12.

[scotthelme.co.uk...]

Does someone have an example of a complete .htaccess Content-Security-Policy line that does not block adsense?
I have not been able to get anything but the loosest Content-Security-Policy to work without blocking some ads.

Also, a Referrer-Policy line that does not cause an error in Chrome?

Ignore my comment about errors in chrome - I had a misbehaving plugin.

Still interested in what Content-Security-Policy settings people are using with adsense though.

*Please, no one post their exact security headers (for obvious reasons.)

@glitterball - Every site will be different. Use the examples found lower on the page at this link: [scotthelme.co.uk...]

You have to consider what type of vulnerability your site has. If you have a highly susceptible CMS like WP, I would include inline CSS protection and script injection protection.

@glitterball - Every site will be different. Use the examples found lower on the page at this link: [scotthelme.co.uk...]

Not very helpful given the last paragraph on that page (The Problem).

I was asking specifically about settings that allow adsense to work properly - I don't see how a generic line with (possibly) a few google domains could be a security risk.

There are various versions of a CSP that allows Adsense. This is the code Google recommends:

Header set Content-Security-Policy "script-src 'self' https://apis.google.com"

However, exact syntax will depend on your server config. If you use a redirect (example to www or HTTP to HTTPS) you may need you use your full domain path "https://www.example.com" instead of "self"

This is the basic CSP for allowing Adsense, however it does not protect from other threats. That's why you *must* build your own, depending on your site.

@keyplyr Thanks for that, unfortunately, for me, that blocks Adsense and Chrome returns errors such as:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src https://www.example.com [apis.google.com"....] Either the 'unsafe-inline' keyword, a hash ('sha256-etc'), or a nonce ('nonce-...') is required to enable inline execution.

Using 'self' instead of https://www.example.com produces the same result.

Then you need to allow inline script, add that to the CSP. I think its in those examples in that link.

To work on individual issues, you should start a new thread and title it appropriately.

@keyplyr You would also need to add every top-level localised Google domain (and others). In which case, it's impractical.

That's not an accurate statement.

I think you're missing the point. This is not a theoretical concept for debate.

The above listed security headers, including the CSP, are practical applications in use by hundreds of thousands of front facing web sites and quickly becoming a standard of security for both the site owner and the visitor.