17

Does anyone know how to get CSP, even with the default-src wildcard, to work so a modern Analytics script sends website per-page data (not just home page data) to the site owner's account and so AdSense ads appear?

I tried many variations of CSP for my website, including that proposed in <H5BP.com>'s .htaccess file, but all blocked Google Analytics from producing per-page data (except for the home page) and Google AdSense from accepting ads on any page.

Google's machines did not see the Analytics script although Google's humans always saw it in my website source code. Even setting CSP default-src to the asterisk wildcard failed.

Asking at a Google forum and a non-Google forum got nothing that worked except that people said the problem was with my CSP and I received one email that said that I should comment CSP out completely. That last worked. Commenting out should be no better than default-src wildcard but commenting out is the only way I got ads and inside-the-website data.

No Stack Overflow thread is about CSP and AdSense. When I proposed that H5BP tell users about this in their model <.htaccess>, their respondent said it works for him and referred me to you.

As a check on advice, is anyone seeing that page-specific data in their own Google Analytics account and seeing AdSense ads while running .htaccess CSP?

Community
  • 1
  • 1
Nick
  • 281
  • 2
  • 5
  • Really not clear what the specific problem is. – charlietfl Jan 08 '16 at 03:44
  • Trying to write CSP into .htaccess even if permissive without limit and need to know how from the experience of someone who actually receives per-page inside-website Google Analytics data and has AdSense ads actually appearing while using .htaccess CSP. – Nick Jan 08 '16 at 04:01
  • That doesn't tell us what code you are using or what is blocking. Suggest reading: http://stackoverflow.com/help/how-to-ask – charlietfl Jan 08 '16 at 04:02
  • The JavaScript code are the scripts supplied by Google for Analytics and AdSense over the last few months (not old versions) and every variation of CSP that I tried was blocking, including the default-src wildcard. – Nick Jan 08 '16 at 04:13
  • Yes it's possible. What policy have you tried and what error message is showing in Chrome console when it blocks? Please give specific details and error messages and not just a ramble that you tried lots of things but it didn't work. Default-src is all well and good but if you are then specifying a script-arc after then it will be ignored. – Barry Pollard Jan 08 '16 at 06:19
  • The 24 CSPs and the messages are 35x too long for SO. Is there any other way to provide them? Briefly: Default-src wildcard was alone. Else, default-src was trailed only by sha256- value/s and/or an inline comment or was last. Analytics said: "Missing Tracking Code . . . .". Tonight, I ran: Header set Content-Security-Policy "default-src *" Chromium wouldn't run Google scripts or apply inline style to them; saying they violated 'Content Security Policy directive: "default-src *". . . .' After I deleted the CSP, most Chromium messages vanished and 5 ads ran. – Nick Jan 09 '16 at 04:14
  • You could try to use the 'unsafe-inline' or the 'unsafe-eval' keywords. If adsense or analytics use inline javascript or the eval function this might help. [Reference and a security considerations](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives#Keywords) – Phonolog Jan 15 '16 at 10:04
  • Tried in last hour or so (Header set Content-Security-Policy "script-src 'unsafe-inline' 'unsafe-eval'; default-src *") but got 24 new red messages in Chromium and lost ads. StackOverflow limits space but I can send details. Didn't wait long enough (maybe a day) for Analytics per-page data and "'unsafe-inline' . . . enable[s] . . . attacks . . . [and is] best avoided completely" (CSP level 2). Deleted CSP and got ads again. Something else to try? Thanks. – Nick Jan 19 '16 at 06:46
  • Any updates on this in 2022? – Lars Flieger Aug 05 '22 at 13:45

5 Answers5

4

No. As of today [8 Sep 16]. We disabled CSP as Google frame source was domain specific -> frame-src : … google.co.uk google.co.fr ...

phani
  • 1,134
  • 1
  • 11
  • 24
4

Adsense

For Google adsense, e.g. this CSP "works":

Content-Security-Policy: frame-ancestors 'self';

It prevents your page being framed without putting limits on what your page can do. Hence its XSS protection is nonexistent.

But the Adsense scripts can be loading something that loads, which in turn loads etc. And given the thousands (at the time of writing: 3103 ) 3rd party advertising networks they can use, there simply is no reasonable nor practicable way for us to ever know what all of them could be needing for the ads to function. So to restrict where you're going to let images, flash, javascript etc. be loaded from if you want to have Adsense just is not going to happen.

One or the other:

  • either Adsense
  • either a restrictive CSP

But not both.

Analytics

is another matter, already covered in other replies. [not a user]

CSP policies

Potential authors of permissive CSP policies need to be reminded that e.g. https: and * do not include permission for unsafe-inline nor data: sources. I've seen quite a few places around the web where authors assume they do.

While writing policies it might be better to put a report-only one up first. The header is named "Content-Security-Policy-Report-Only" instead of "Content-Security-Policy" and it'll not stop anything, just do the reporting part in json to the specified destination. See here: https://developers.google.com/web/fundamentals/security/csp/#report-only

  • 2
    That's sensible and one reply from last September apparently from Google (@phani) is consistent with that. I would rather Google had told us directly as that would have saved me, as a site designer, a bunch of time. It's likely their method of disabling CSP, in which even the totally permissive configuration is unacceptable, likely affected per-page Analytics as well as AdSense. I don't see anyone claiming to get per-page Google Analytics data and also having CSP on their website. So, I don't plan to put CSP back into any website that has either Google product. Thank you. – Nick Jul 03 '17 at 17:43
  • The main problem I see is that people trying to write a permissive CSP need to be reminded that * does not allow unsafe-line nor data: . But if you're going to allow everything, you might as well not write a limit for that type of resource to start with. The example above shows how you can prevent being "framed" using CSP while not putting restrictions on what you load. –  Jul 03 '17 at 23:39
1

Or log all error with report-uri for add sources to your CSP.

JSON will POST to that URL (https://example.com/csp/log.php).

Content-Security-Policy: default-src 'self';
report-uri: https://example.com/csp/log.php;
Gustavo Morales
  • 2,614
  • 9
  • 29
  • 37
Oznog
  • 23
  • 5
1

With strict CSP 3, and nonces, I think this is possible but I don't have the ability to test as we don't use AdSense.

1.) Put all javascript in (GA, AdSense, etc.) in .js files. No inline JS.

2.) Use the proposed "strict" CSP: https://csp.withgoogle.com/docs/strict-csp.html

3.) Include the .js files as you normally include any file, but add a nonce: 

<script src="/mygooganalytics.js" nonce="[your nonce here]"></script>

The effect should be that anything originating from mygooganalytics.js will be allowed. Nonces are generally created by server-side code (php, ruby, etc.), but if this is outside of your app/in a regular old html file you can generate a nonce using your server. If you happen to use Apache: Generate a nonce with Apache 2.4 (for a Content Security Policy header)

KayakinKoder
  • 3,243
  • 3
  • 23
  • 37
  • Interesting. I hesitate to experiment on this till others have, and have reported. The withgoogle link is Google's own (that's good), the last FAQ implies that Win exposure (thus most users) is unprotected, and Google is still not officially saying CSP and AdSense/Analytics will coexist (it probably won't unless maybe if the experiment works). If someone uses another ad supplier, especially with dynamic ads, it'd help to know if CSP works with that supplier. – Nick Jul 15 '17 at 21:32
  • Yes I would definitely give it a try on a small scale first. We do use something that might be similar on a technical level to AdSense, Intercom.io. With previous versions of CSP, we had to whitelist about 2 dozen of their URLs, including SaaS they used internally (wistia, for example). With CSP 3, we simply have an intercom.js file with a nonce. I won't link to their site because it will eventually change I'm sure, but search "intercom csp", they have a nice page "Using Intercom with Content Security Policy" describing CSP 1 and 2 url whitelisting vs. CSP 3/nonces. – KayakinKoder Jul 16 '17 at 13:42
0

Using below code works for me : 

default-src 'self' googleads.g.doubleclick.net;
script-src 'self' 'unsafe-inline' data: pagead2.googlesyndication.com storage.googleapis.com googleads.g.doubleclick.net ajax.googleapis.com; 
img-src 'self' data: storage.googleapis.com pagead2.googlesyndication.com; 
style-src 'self' 'unsafe-inline'; 
font-src 'self' fonts.googleapis.com; frame-ancestors 'self'; object-src 'self'
Bhushan Gadekar
  • 13,485
  • 21
  • 82
  • 131
Oznog
  • 23
  • 5
  • 1
    This helped me a lot as I started recently seeing errors on Adsense ads loading. Only thing I didn't include was that **data:** option on any of the -src entries as it's insecure and adsense works without it using all the above domains you specified :+1: – MitchellK Nov 22 '17 at 10:59
  • 11
    This is not an acceptable solution. Using `'unsafe-inline'` within `script-src` pretty much negates the whole use of the CSP. Source: https://blog.mozilla.org/security/2014/10/04/csp-for-the-web-we-have/ – maninak Jun 22 '18 at 13:36
  • I think this works mainly for non-secure sites, which is also a problem. Traffic should really be SSL only these days, so use the https:// – Jeffrey Gilbert Mar 17 '22 at 20:45