Cómo proteger una aplicación Blazor WebAssembly de la decompilación

Blazor WebAssembly es una forma genuinamente excelente de escribir una SPA en .NET. También es el objetivo más expuesto al que puedes enviar .NET, y la mayoría de los ofuscadores lo ignoran discretamente. Si tienes lógica propietaria, una comprobación de licencia o un algoritmo que preferirías que la competencia no leyera, este es el modelo de despliegue que más fácilmente lo entrega.

Por qué Blazor WASM es el objetivo .NET más expuesto

Una aplicación Blazor WebAssembly ejecuta tus ensamblados .NET reales y compilados en el navegador. Para hacerlo, los descarga: abre la pestaña de red en cualquier sitio Blazor WASM y verás la carpeta _framework transmitiendo archivos .dll y .wasm. Esos son tus ensamblados: los de verdad, no una aproximación minificada.

Cualquiera puede guardarlos y abrirlos en un decompilador gratuito como nuestro propio Glass.NET. Como explicamos en ¿se puede decompilar el código .NET?, un ensamblado gestionado es un plano casi completo de tu código fuente: nombres de tipos y métodos, flujo de control y cada cadena literal vuelven directamente. En el servidor, al menos las DLL se quedan en tu máquina. En Blazor WASM, las estás enviando a cada visitante.

Por qué no puedes limitarte a ofuscar las DLL

La solución obvia —pasar tus ensamblados por un ofuscador y dejarlos caer en la salida de publicación— no funciona con Blazor, y esta es justo la razón por la que la mayoría de las herramientas lo omiten. El cargador de Blazor hace dos cosas que rompen un intercambio ingenuo:

1. Comprobación de integridad. blazor.boot.json contiene un hash SHA-256 de cada ensamblado. Reemplaza una DLL por una ofuscada y su hash deja de coincidir: Blazor se niega a cargarla.
2. Copias precomprimidas. Una aplicación publicada entrega copias .br (Brotli) y .gz de cada archivo, que el runtime prefiere. Ofusca solo el .dll en bruto y el navegador cargará tan contento la copia comprimida obsoleta en su lugar.

Así que proteger Blazor no es solo “ofuscar el ensamblado”: es “ofuscar el ensamblado y reparar el manifiesto de arranque y las copias comprimidas para que cuadren”. Falla cualquiera de las dos y obtienes una pantalla en blanco.

Proteger una aplicación Blazor con Nebula

El comando nebula blazor de Nebula hace todo el proceso de principio a fin. Publica como de costumbre y luego apunta Nebula a la carpeta _framework:

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

Nebula ofusca los ensamblados de la aplicación usando tu configuración, luego recalcula los hashes de integridad en blazor.boot.json y regenera las copias .br/.gz para que todo encaje. La aplicación protegida arranca exactamente igual que la original: la diferencia está en lo que un visitante encuentra cuando abre las DLL. Recorrido completo en Proteger Blazor WebAssembly.

Todo lo que hay en el arsenal de Nebula se aplica a los ensamblados que protege:

• El renombrado elimina los nombres de tipos, métodos y campos.
• El aplanado del flujo de control destruye la estructura que reconstruye un decompilador.
• El cifrado de cadenas saca del archivo los literales reveladores.
• La virtualización de código (Enterprise) elimina por completo el IL de tus métodos más sensibles, reemplazándolo por una llamada a una VM embebida. Y lo que es crucial: el runtime de Nebula apunta a .NET Standard 2.0, de modo que los métodos virtualizados se ejecutan dentro de WebAssembly igual que en el escritorio; consulta virtualización de código.

Qué proteger, y qué sigue correspondiendo al servidor

La ofuscación cambia la economía de la ingeniería inversa, pero no deroga la regla básica del código del lado del cliente: cualquier cosa que se ejecute en la máquina del usuario puede, en principio, inspeccionarse en la máquina del usuario. Así que la división es sencilla.

Endurece en el cliente: algoritmos propietarios, lógica de precios o de puntuación, comprobaciones de licencia y funciones, cualquier cosa que sea tu propiedad intelectual y tenga que ejecutarse en el navegador.

Mantén en el servidor: los secretos de verdad. Las claves de API, las claves de firma y las decisiones autoritativas sobre derechos pertenecen detrás de una API, no compiladas en un ensamblado que envías a cada visitante, ofuscado o no. Nebula hace que el código del lado del cliente sea caro de leer; tu backend hace que los secretos sean imposibles de alcanzar.

Pruébalo

Si envías Blazor WebAssembly, abre primero tu propia carpeta _framework publicada en Glass.NET y lee un componente que consideres propietario: es una forma rápida de ver la exposición. Luego ejecuta nebula blazor sobre la misma salida y vuelve a mirar.

Descarga Nebula.NET para probarlo, o lee la guía de protección de Blazor y la lista completa de funciones.