Blazor Dlls - Can users access them and decompile?

Question

Forgive me if I am missing something obvious with Blazor, but with the dlls being present in the browser as javascript files would be, is it possible for users to download the dll files and see the execution code by decompiling the files and/or run them out side of the browser?

This seems to present a very clear security concern if developers are not aware that their library code is visible as their javascript code already is.

Answer 1

Of course they can, those DLLs are just static files served by the Web Server. I'd recommend reading this excellent blog post on how the browser runs those DLLs:

In interpreted mode, the Mono runtime itself is compiled to WebAssembly, but your .NET assembly files are not. The browser can then load and execute the Mono runtime, which in turn can load and execute standard .NET assemblies (regular .NET .dll files) built by the normal .NET compilation toolchain.

If you don't want the user to reverse-engineer (easily) your code, then the answer is code obfuscation. Blazor does not plan to provide such functionality, any standard .NET obfuscator should work. I haven't tried myself, but I'm sure it would be a bumpy road.

Answer 2

Yes indeed.

This is part of the reason why there are 2 Blazor flavors:

1. Blazor WebAssembly (i.e. client side Blazor)
2. Blazor Server

Blazor Server apps will only ever respond to the browser with the following file:

• index.html
• css
• blazor.server.js
• Other usual stuff (e.g. img's fonts, etc)

All the rendering code and other code (your awesome libraries with your awesome code) will run on the server.

Using SignalR, the browser and server will constantly stay in touch (usually via websockets), and whenever the UI needs to change, the server will make calculations and tell the browser how to re-render the UI. All this magic happens in the browser thanks to that blazor.server.js file.

With this pattern, no DLL's are required on the browser

Now, when it comes to Blazor WebAssembly (client side flavor), you probably don't want to deliver to the browser any sensitive proprietary code, etc. Sure, you can always use tools to obfuscate your code, but you probably want to make API calls where possible and have sensitive code run on the server.