Protección de Blazor WebAssembly

Blazor WebAssembly envía tus ensamblados .NET reales al navegador, donde cualquiera puede descargarlos y decompilarlos desde _framework. Eso lo convierte en el objetivo .NET de mayor exposición que existe — y en el que la mayoría de los ofuscadores no manejan correctamente.

El problema es que no puedes limitarte a ofuscar las DLL de una aplicación publicada: Blazor verifica cada ensamblado contra un manifiesto de integridad SHA-256 (blazor.boot.json) y se niega a cargar cualquier cosa cuyo hash no coincida, y sirve copias precomprimidas .br/.gz que también deben coincidir. Ofusca una DLL a mano y la aplicación sencillamente no arrancará.

El comando blazor de Nebula se encarga de todo: ofusca los ensamblados de la aplicación y repara el manifiesto y las copias comprimidas, de modo que la aplicación protegida carga con normalidad.

Uso

Publica tu aplicación como de costumbre y luego ejecuta Nebula contra la carpeta wwwroot/_framework publicada:

dotnet publish -c Release -o publish
nebula blazor --framework publish/wwwroot/_framework --config nebula.config.json

• --framework — el directorio wwwroot/_framework de la aplicación publicada.
• --config — tus ajustes de ofuscación (no hace falta inputs; Nebula proporciona cada ensamblado).
• --assembly <Name> — protege un ensamblado concreto (repetible). Por defecto: el ensamblado de entrada de la aplicación. Los ensamblados de framework/BCL nunca se tocan.

Para cada ensamblado protegido, Nebula: lo ofusca, recalcula su entrada sha256-… en blazor.boot.json y regenera sus copias .br y .gz — y luego reescribe el manifiesto y sus propias copias comprimidas. El resultado supera la comprobación de integridad del navegador y se ejecuta exactamente igual que antes.

Qué proteger

Los ensamblados de tu aplicación — los que contienen tu lógica — son el objetivo. Las reglas de negocio, los precios, las puertas de funcionalidad y cualquier validación del lado cliente son totalmente visibles en una compilación Blazor WASM sin proteger, así que este es justo el punto donde más rinden el cifrado de cadenas, el aplanado del flujo de control y (Enterprise) la virtualización de código.

Requisitos y notas

• Publica los ensamblados como .dll normales (lo predeterminado en la mayoría de las configuraciones). Si tu compilación usa Webcil (ensamblados envueltos en .wasm), desactívalo por ahora con <WasmEnableWebcil>false</WasmEnableWebcil> en tu proyecto — el soporte de desempaquetar/reempaquetar Webcil está planificado.
• Ejecuta nebula blazor después de dotnet publish, sobre la salida publicada.
• El comando aplica el conjunto de funcionalidades de la edición de tu licencia, igual que cualquier otra ejecución de Nebula.
• Recordatorio: el código del lado cliente es intrínsecamente accesible — la ofuscación eleva sustancialmente el coste de leerlo, pero la lógica genuinamente secreta (y los secretos) siguen perteneciendo al servidor.