Make it easier to secure inline scripting, which is used in all Blazor examples I've seen

[jbaumflek]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

cc: @guardrex dotnet/AspNetCore.Docs#34425
related: #6001
Please read the doc issue first.
Having followed examples in Learn, etc., I make use of inline scripting all over my app. I didn't know that would be an issue until "too late" and now I find myself having to rework the entire UI to collocate the js (not even sure what that means yet), just to be able to enable meaningful CSP, which is of course required for our corporate policy. Of course some of this is my ignorance, but I sure wish following OWASP was more built-in, not so much as a separate task. I started this with .NET 6 so perhaps there are templates that already have hardening in the forefront, but if not, I think there should be templates with baked in security.

Describe the solution you'd like

a template for blazor server-side enterprise-level security already configured

Additional context

No response

[guardrex]

Javier/Steve, it would probably be a good idea in relation to @jbaumflek's initial approach to directly address inline JS in the CSP article, probably saying that nonce-source is out of the question and hash-source isn't particularly useful, resulting in a recommendation that devs should generally avoid inline JS-heavy development.

I'm playing with language at dotnet/AspNetCore.Docs#34431.

See the DIFF starting at line 306 to let me know if that's headed in the right direction. 👀

Also, we're keeping an example of applying a CSP via middleware for server-side apps at ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/startup?view=aspnetcore-8.0#server-side-and-prerendered-client-side-scenarios

That's cross-linked in three spots in the CSP article to surface it to readers.

[javiercn]

@guardrex We should either avoid inline JavaScript where possible in the docs or clarify very explicitly that it is done that way for demo purposes and that you should avoid inlining JS into the view directly.

As for guidance on CSP, I don't want us to make the docs an in-depth tutorial about CSP. We should instead steer users to safer practices.

[guardrex]

avoid inline JavaScript where possible in the docs or clarify very explicitly that it is done that way for demo purposes and that you should avoid inlining JS into the view directly.

Thanks ... I understand.

We don't have inline JS anywhere in article coverage, examples, or samples. This is purely about what should be said in a new section or passing remark on it (e.g., for the Location of JS article and the CSP article). What I'll do is ...

• Not cover inline JS explicitly in the CSP article outside of our current, general remarks about adding a hash to the CSP, if needed.
• Only make a passing mention in the JS interop article Overview that we don't recommend using inline JavaScript in Blazor apps.

I don't want us to make the docs an in-depth tutorial about CSP

We've had an aritcle on CSP going nearly back to the beginning of Blazor ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/content-security-policy?view=aspnetcore-9.0

Do you want to consider pulling that article and placing a different article with the 'safer practice' that you mentioned? ... and I'd need to even know what 'safer practice(s)' you're referring to.

UPDATE: Done! 👍 ... I placed a single remark in the JS interop: Location of JS article introductory remarks recommending not to use inline JS, and I made no change to the current CSP article. We're good on the docs side.

I just need to know if you want to replace the CSP article with a different article covering a safer approach. If so, I'll open a new docs issue for the work. Let me know what 'safer approach(s)' we'd cover in such an article.