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.

Freedafreedman

Answer 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: mediastream: blob: filesystem: about: ws: wss: 'unsafe-eval' 'wasm-unsafe-eval' 'unsafe-inline'; 
script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; 
script-src-elem * data: blob: 'unsafe-inline' 'unsafe-eval';
connect-src * data: blob: 'unsafe-inline'; 
img-src * data: blob: 'unsafe-inline'; 
media-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:;

Togoland

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

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

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

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

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' – Aurilia

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

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:; – Fie

Is the above a bad policy for a public website? – Marocain

@Marocain depends on your purpose – Togoland

@Togoland I would like to check the box for "having a CSP", while neither breaking the website, nor taking a step backwards in security. – Marocain

@Marocain I assume this CSP is for websites that have information that should be accessible by anyone even in other websites, you have to decide for yourself if this suits your purpose. or maybe you're testing localhost and can't bother with csp at the moment – Togoland

Answer 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.

Expostulatory

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

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

Coooool. save my time – Quincey

Answer 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

Pot

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

Answer 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';"

Limbourg

Answer 5

DISCLAIMER/WARNING: Please consider writing a proper CSP. The following configuration allows any connection and does not provide any security benefit. The Content-Security-Policy-Report-Only header helps you to archive the goal of a proper CSP in two steps/non-blocking.

Since the default behavior is for every fetch directive to fall back to default-src (according to MDN), we only need to define a default-src and sources for all document and navigation directives (base-uri, form-action, form-ancestor). The simplest CSP header that allows anything should be this:

default-src * data: mediastream: blob: filesystem: about: ws: wss: 'unsafe-eval' 'wasm-unsafe-eval' 'unsafe-inline';
base-uri * data: mediastream: blob: filesystem:;
form-action * data: mediastream: blob: filesystem:;
form-ancestor * data: mediastream: blob: filesystem:;

The explanation why * does not match "everything" is, that the asterix only allows all host-sources, but e.g. schema-sources, inline or eval are not host-sources. Therefore these types of sources must be explicitly specified.

EDIT: added directives that do not fallback to default-src (thanks for the comment)

Molli

Note that "default-src" does not actually apply to "Everything": content-security-policy.com/default-src It doesn't apply to: base-uri, form-action, frame-ancestors, report-uri, sandbox – Skyros