Content Security Policy - Veracode security scan issue

Question

I have a spring boot web application which is deployed using Jboss EAP server. For security scan we use Veracode security tool to perform dynamic scan on running application and I got the issue - missing Content-Security-Policy - https://cwe.mitre.org/data/definitions/829.html.

So I started adding one by one like below in the standalone.xml for script, style file, image file, content file and data

<response-header name="Content-Security-Policy" header-name="Content-Security-Policy" header-value="default-src ; style-src * 'unsafe-inline' data: https:; script-src * 'unsafe-inline' 'unsafe-eval' https:; img-src * data: 'unsafe-inline'; frame-src * 'unsafe-inline' data: https:; connect-src * 'unsafe-inline' data: https:;"/>

But now the veracode tool complains on using the 'unsafe-inline'

As of now, I am not able to move the javascript files to the new file and it involves lots of effort in development and testing because we have nearly 2500 html/jsp files where the javascript files are referenced.

so I have only two options as per the CSP documentation - example: https://csper.io/blog/no-more-unsafe-inline,

1. Nounce or Hash: This I will keep it as second option as it involves code changes and testing on 100+ features in the application.
2. Switch to Report-Only and use a report-uri service Does anyone tried this solution and how to achieve this?

Thanks,
Harry

Answer 1

Switching to Report-Only and a report-uri/report-to service will only you make you able to understand after the fact that something happened. It will not offer any type of protection. It is meant as a tool to aid development of the policy and test new policies in a safe way.

You only need to add CSP to document files. It has no function on .js, .css, image files and data.

You don't need 'unsafe-inline' for your .js and .css files, you will typically allow these with 'self' if you load them from the same origin or the host name if you load them from somewhere else.

You will need 'unsafe-inline' for inline script/style in your documents or injected script/styles until you rewrite these or allow them by other measures such as hash or nonce.

It is also worth noting that the risk of style XSS is negligible if you lock down the rest of your CSP.

Hope this helps to clarify what is needed.