10

We had a penetration testing and one of the findings were:

"Missing Content-Security-Policy HTTP response header"

We did a bit of research and found out how to set this in the web servers httpd.conf file. The problem is we don't know what to include exactly. Our web app doesn't really have any dependencies to external sites like googleapis or any CDN or external images on the net. So, we aren't really sure what to put.

Below is a sample but this has dependencies to some google links. 

<Location "/CompanyXYZ/">
Header always append X-Frame-Options deny
Header always set Content-Security-Policy "default-src 'self' data: blob: *.google.com *.gstatic.com; style-src 'self' 'unsafe-inline' *.google.com *.googleapis.com; script-src 'self' 'unsafe-inline' *.googleapis.com *.google.com;"
</Location>

What if we have none of those dependencies? how should we set ours?

lecarpetron dookmarion
  • 519
  • 2
  • 7
  • 18

3 Answers3

7

One thing to clear up here is that policy doesn't "have dependencies" on the google links. It's a policy that is allowing the user's web browser to load content from those domain when they load your app. The CSP policy is denying the user's browser permission to load anything else.

A lack of a CSP policy should not be considered a vulnerability. I would hope that is rated as a 'note' or very low risk issue. Implementing CSP is something you do need to test since you can easily break functionality on your site/app. I would just be sure you're not rushed into this to satisfy a vendor.

CSP is something that should be done more carefully than this, you need to carefully evaluate all the content loaded/included by your app. Then it would be prudent to implement a policy in report-only mode where you can see violations that would have violated the policy. This way you can find problems without the risk of breaking functionality to users.

This is its own can of worms since you need a reporting listener (there are platforms available online for this).

If you do choose to wing it and just implement the policy

If you don't rely on the resources from those domains you safely omit them. They are left in there as examples since so many sites include content from those CDNs.

One last option is to just include a very minimal policy that basically does nothing. Most pentest vendors are just checking a box to see if exists.

You could try the following to check the box (warning this does nothing):

Content-Security-Policy: "default-src *"
sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
ebuntu
  • 151
  • 1
  • 8
  • Try this: [https://report-uri.com/home/generate](https://report-uri.com/home/generate) – Matt Jul 20 '22 at 15:05
1

A lack of a CSP policy should not be considered a vulnerability. I would hope that is rated as a 'note' or very low risk issue. Implementing CSP is something you do need to test since you can easily break functionality on your site/app. I would just be sure you're not rushed into this to satisfy a vendor.

A properly configured Content-Security-Policy (CSP) can help prevent cross-site scripting (XSS) attacks by restricting the origins of JavaScript, CSS, and other potentially dangerous resources. @ebuntu What makes you believe this is not a vulnerability?

Royston
  • 433
  • 2
  • 9
  • 25
0
<Location "/app-services">
                Header set x-xss-protection "1; mode=block"
                Header set X-Content-Type-Options nosniff
                Header set Referrer-Policy "strict-origin"
                Header add Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src * 'self' data: https:;"
                Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=strict
</Location>

<IfModule mod_headers.c>
 Header set x-xss-protection "1; mode=block"
</IfModule>

So above config is added in apcahe config for setting samesite as strict , x-xss-protection "1; mode=block", set secure flag and Content-Security-Policy

Parameshwar
  • 856
  • 8
  • 16