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?
To add this custom meta tag, you can go to www.yourStore.com/Admin/Setting/GeneralCommon and find Custom <head> tag and add this as shown in the image below. Content Security Policy protects against Cross Site Scripting (XSS) and other forms of attacks such as ClickJacking.
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 policyIf 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 *"
You can try a CSP Generator if you want an easy way to play with it: https://www.cspisawesome.com/content_security_policies
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With