Allow All Content Security Policy?

Question

Is it possible to configure the Content-Security-Policy to not block anything at all? I'm running a computer security class, and our web hacking project is running into issues on newer versions of Chrome because without any CSP headers, it's automatically blocking certain XSS attacks.

Solution 1

For people who still want an even more permissive posts, because the other answers were just not permissive enough, and they must work with google chrome for which * is just not enough:

default-src *  data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval' 'unsafe-dynamic'; 
script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; 
connect-src * data: blob: 'unsafe-inline'; 
img-src * data: blob: 'unsafe-inline'; 
frame-src * data: blob: ; 
style-src * data: blob: 'unsafe-inline';
font-src * data: blob: 'unsafe-inline';
frame-ancestors * data: blob: 'unsafe-inline';

Solution 2

It's not secure at all, but as staring point the real allow all policy is:

default-src * 'unsafe-inline' 'unsafe-eval'; script-src * 'unsafe-inline' 'unsafe-eval'; connect-src * 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src *; style-src * 'unsafe-inline';

See: https://content-security-policy.com/ and this CSP migration guide.

Solution 3

The best way would be not applying any policy.

But to answer your question, an "allow all policy" would probably be:

default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; 

Note: untested

Solution 4

Here's the htaccess code to allow everything in CSP

Header add Content-Security-Policy "default-src *  data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval' 'unsafe-dynamic'; script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; connect-src * data: blob: 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src * data: blob: ; style-src * data: blob: 'unsafe-inline'; font-src * data: blob: 'unsafe-inline';"

View more solutions

Comments

[joshlf]

Unfortunately without any policy in place, Chrome proactively adds some XSS protections of its own, so having nothing is actually worse. But thanks!

[basil]

Blob and data missed, example: default-src * data: blob: 'unsafe-inline' 'unsafe-eval';

[Rob Breidecker]

For a policy that allows inline, but not from any host, the wildcards ( * ) could be changed to "self".

[Anatol Bivol]

Chrome now says it doesn't know and will ignore 'unsafe-dynamic'

[Rainb]

@AnatoliiBivol interesting, I guess you can remove it to avoid warnings, if chrome is the only thing you care about

[Jonathan Parker]

You missed font-src: * 'unsafe-inline';

[Jonathan Parker]

I also needed to add frame-ancestors developer.mozilla.org/en-US/docs/Web/HTTP/Headers/…

[Dat Ho]

Coooool. save my time

[Ahmed El-Atab]

As if a directive is not found a fallback will be applied to the 'default-src' directive, why don't you consider something like that: default-src * data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval'

[Rainb]

@AhmedEl-Atab at the time of writing, chrome required defining each entry explicitly.

[Kevin .NET]

New version on 2022: default-src * data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval'; script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; connect-src * data: blob: 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src * data: blob: ; style-src * data: blob: 'unsafe-inline'; font-src * data: blob: 'unsafe-inline'; frame-ancestors * data: blob:;