Unsafe-inline and unsafe-eval

Question

Unsafe-inline and unsafe-eval

Venugopal 20

Hi All,

We have an application developed in ASP.NET (.NET Framework 4.6.2). Understand from the below article that we need unsafe-inline and unsafe-eval settings in order to run the application.

https://techcommunity.microsoft.com/blog/iis-support-blog/content-security-vulnerability-in-asp-netwebforms/3951304

Our PT team highlighted that these are vulnerable configurations.

Below controls are in place on our end and would like to know whether this is sufficient so that it is not exploitable.

XSS protection enabled
Access control allow origin
Strict Transport security HSTS enabled
X frame options set to same origin
Other CSP settings like scriptsrc, stylesrc with only specific domain
Additional controls in place like WAF controls to protect from DDoS, network protocol and volumetric attacks, Application layer attacks.

Need your help to suggest on this. Thank you.

Regards

Venugopal

Albert Kallal 5,591 Reputation points

2025-11-12T21:28:33.9433333+00:00

Are these public facing web pages, or is a logon required to reach such pages? If such pages don't require a logon, then more love and care is required. If such pages require a logon, then you have at least additional wiggle room. I mean, if someone is already on a page that they shouldn't be, then that's probably already worse of a issue.

More often then not, it comes down to what data (the database) the given page is to work with, and what information that page exposes. If your server side code has good verification, or say talks to the database through a class (some kind of ORM), then again, the vulnerability here is very low.

And keep in mind, that new frameworks (at least most) compared to webforms have BOATLOADS more client side code, and moving parts - and that's where the most of the vulnerableness come into play. Since WebForms tends to be VERY heavy server side, then a good number of these worries and precautions are thus reduced quite a bit.

So, much of these depends on who can use + access those pages....

Answer accepted by question author

2 additional answers

Your answer

Albert Kallal 5,591 Reputation points

2025-11-12T21:28:33.9433333+00:00

Are these public facing web pages, or is a logon required to reach such pages? If such pages don't require a logon, then more love and care is required. If such pages require a logon, then you have at least additional wiggle room. I mean, if someone is already on a page that they shouldn't be, then that's probably already worse of a issue.

More often then not, it comes down to what data (the database) the given page is to work with, and what information that page exposes. If your server side code has good verification, or say talks to the database through a class (some kind of ORM), then again, the vulnerability here is very low.

And keep in mind, that new frameworks (at least most) compared to webforms have BOATLOADS more client side code, and moving parts - and that's where the most of the vulnerableness come into play. Since WebForms tends to be VERY heavy server side, then a good number of these worries and precautions are thus reduced quite a bit.

So, much of these depends on who can use + access those pages....

Answer 1

Thanks for reaching out.
You are correct that the article mentions adding unsafe-inline and unsafe-eval in the Content Security Policy (CSP) for ASP.NET WebForms applications to function properly. However, these directives significantly weaken CSP and are considered vulnerable because they allow inline scripts and dynamic code execution, which can lead to XSS attacks.

Why this happens

ASP.NET WebForms uses inline JavaScript for features like __doPostBack and client-side validation.
CSP blocks inline scripts unless unsafe-inline or a nonce/hash is used.
Adding unsafe-inline and unsafe-eval bypasses CSP protections.

Recommended Approach

Avoid unsafe-inline and unsafe-eval if possible Instead, use nonce-based or hash-based CSP for inline scripts: Content-Security-Policy: script-src 'self' 'nonce-<random>' https://trusted.cdn.com; Update your app to inject nonces for inline scripts. Upgrade or Refactor Consider upgrading to ASP.NET Core or refactor inline scripts into external files to remove the need for unsafe directives. Defense-in-Depth Controls The controls you listed (HSTS, X-Frame-Options, WAF, domain-restricted CSP) are good additional layers, but they do not fully mitigate XSS risk if unsafe-inline is present.
Validate and Encode Ensure proper input validation and output encoding throughout the application.

References

Content Security Policy (CSP) Best Practices
Microsoft Guidance on ASP.NET WebForms CSP.

Let me know if the issue persists after following these steps. I’ll be happy to assist further if needed. If the issue has been resolved, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Gade Harika (INFOSYS LIMITED) 1,945 Reputation points Microsoft External Staff

2025-11-11T09:59:38.69+00:00

Hope you're doing well! Please let us know if the issue persists or resolved. If the answer is helpful, please click Accept Answer and kindly approve it. If we didn't get any response from your side. we will proceed to close the thread by November 17th.
Gade Harika (INFOSYS LIMITED) 1,945 Reputation points Microsoft External Staff

2025-11-13T12:10:26.05+00:00

Hope you're doing well! Please let us know if the issue persists or resolved. If the answer is helpful, please click Accept Answer and kindly approve it. If we didn't get any response from your side. we will proceed to close the thread by November 17th.

Answer 2

Bruce (SqlWork.com) 81,971 Volunteer Moderator

special care is required if you use HtmlHelper.Raw().

note: you can have all these default safeguards, but you must verify your code does not allow exploits. this means validating all post back values. always verify the user has access to to a data fetched by key.

Answer 3

Venugopal 20

Hi Gade Harika,

Thank you for the suggestion. We will try with the recommended approach and let you know if any further clarification required.

Share via

Unsafe-inline and unsafe-eval

Recommended Approach

2 additional answers

Your answer