Does server-side rendering keep my application logic private?
It keeps whatever stays on the server private, which is the point, but it says nothing about the JavaScript that ships alongside the rendered markup. A Razor page renders HTML on the server and then delivers script files from wwwroot exactly as any other site would. The validation rules, pricing calculations, feature checks and API call sequences written in that script are downloaded in full. Server-side rendering is a strong architecture for keeping logic private precisely because you can move logic into it, not because rendering hides the client code you still ship.
Can JavaScript Obfuscator protect a Blazor WebAssembly application?
It protects the JavaScript in that application, which is a real but partial surface. A Blazor WebAssembly build downloads compiled .NET assemblies to the browser, and those assemblies are intermediate language rather than JavaScript. A JavaScript protection tool does not transform them, and we will not pretend otherwise. What it does cover is the interop layer you wrote, any JavaScript libraries you ship, and initialisation or glue script in wwwroot. For the managed assemblies themselves you need a .NET obfuscator, and for anything genuinely sensitive the durable answer is to move it behind a server endpoint.
Is Blazor Server safer than Blazor WebAssembly for proprietary logic?
For keeping logic off the client, yes, and by a wide margin. In the server hosting model your component code executes on the server and the browser receives rendered updates over a persistent connection, so the logic never becomes a downloadable artifact at all. What the browser does receive is the framework script and whatever interop or enhancement JavaScript you added, which is the part worth protecting. The trade is operational rather than architectural: a live connection per user, latency on interactions, and reconnection behaviour to design for.
How do I protect script that is embedded inside an .aspx or .cshtml page?
The two cases differ. For classic Web Forms and similar server-template pages, the Mixed Server Code option is designed for exactly this: it locates script regions inside files that are not pure JavaScript and protects them while leaving the surrounding markup and server tags byte-identical. Its documented targets are .aspx, .php, .jsp and .html pages, and it is an Enterprise-tier option. Razor .cshtml files are not in that list, so for modern ASP.NET Core the supported route is to move script out of the view into .js files under wwwroot and protect those, which is also what a strict content security policy will push you toward anyway.
What goes wrong when a server tag sits inside a JavaScript expression?
It stops being valid JavaScript until the server has rendered it, which is the central difficulty with mixed files. A line such as a variable assigned from a server expression is a template instruction, not a program, so the protector has to treat the tag as an opaque token and preserve it exactly. Two rules follow directly. Never let a server tag straddle a statement boundary, because the parser needs complete statements on either side. And always smoke-test the rendered page rather than the template, because the template is not what runs in a browser.
Which files in wwwroot should the protection step actually process?
Your own built output, and not much else. Point it at the site scripts you wrote or bundled, and exclude vendor directories, package-manager-restored libraries, framework runtime files and polyfills. Protecting a third-party library gains you nothing, costs build time, and occasionally breaks a package that checks its own internals. Source maps should be kept out of the published artifact entirely, since a map next to a protected file undoes the work in one request.
Does a MAUI Hybrid or WebView2 desktop application change the answer?
Only in the sense that the files sit on the user machine instead of a web server, which makes casual inspection easier rather than harder. The web assets are packaged with the application and can be read out of it, and the embedded browser ships the same developer tools as the standalone one. Treat that bundled web content the same way you would treat a public site: protect what you ship, and keep the operations that matter behind either your server or the compiled .NET side of the application, where a customer with a file browser cannot reach them.
Where should authority live in a .NET application?
On the server, and .NET teams have an unusually easy time of this because a server is already part of the architecture. Licence validation, entitlement checks, pricing and discount rules, quota enforcement and anything that decides what a user is allowed to do belong in an endpoint that authenticates its caller. The client then asks and renders the answer. Protecting the front end raises the effort required to lift the interface logic that remains and to tamper with the shipped bundle undetected, which is worth having on top of that arrangement rather than instead of it.