Alternative for unsafe-inline in content-security-policy in ASP.NET web app

Question

0.00/5 (No votes)

See more:

We are having a web application built on asp.net platform. We have lot of inline scripts and AJAX tool kit in the application. One of our client want to implement content-security-policy because they want to host application on public url. after ZAP scan we have got vapt of "unsafe-inline".

After lot of research we found solution like nonce/hash. We tried implementing that as well but in the nonce some JavaScript was not working which we identified.

Is there any other way to remove this VAPT.?

What I have tried:

1) Tried by adding tag on web.config script-src 'sefl' 'nonce SOME VALUE' and used nonce in script tag on the .aspx page but didnt work.

Now we are trying to put all the scripts in single js file.

What will be the chances that after replacing this the vapt will remove.?

Posted 20-Jun-22 1:40am

Param From Mumbai

Add a Solution

Comments

Richard Deeming 20-Jun-22 7:56am

A NONCE is a Number used ONCE. Using the same static value on every request defeats the purpose.

Richard Deeming 20-Jun-22 7:59am

Also, if you're using WebForms, you'll find it emits a lot of inline scripts which you can't annotate to comply with a CSP that doesn't allow unsafe inline scripts. For example, many controls will have an onclick attribute to wire up an event handler.

If you don't want to allow unsafe inline scripts, you'll probably need to rewrite the application in a different framework which gives you better control over the generated HTML.

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)