Browser Security Context

When protecting WebAssembly applications with Shield, it's essential to understand the security context imposed by browsers and how Shield works within these constraints.

The Browser Security Sandbox

WebAssembly modules run within the browser's security sandbox, which imposes specific limitations:

• No direct access to the operating system
• Limited access to system resources
• Same-origin policy restrictions
• Isolation from other browser tabs and websites
• Memory safety and bounds checking

These security features protect users but also create a unique environment that Shield must navigate when applying protections.

WebAssembly Security Model

Memory Isolation

WebAssembly uses a linear memory model that is isolated from the JavaScript environment:

• Memory is accessed through a typed array
• No direct pointer manipulation
• Memory can only grow, not shrink
• No direct access to the JavaScript heap

Shield optimizes its protections to work within this memory model while maintaining strong security.

Code Execution Constraints

WebAssembly modules have execution constraints:

• No self-modifying code
• Deterministic execution
• No arbitrary jumps (structured control flow)
• Type safety enforced by validation

These constraints influence how Shield applies control flow obfuscation and other protections.

Shield's Approach to Browser Constraints

Pre-Compilation Protection

Shield applies most protections during the .NET to WebAssembly compilation process:

1. Transforms .NET IL code before it's compiled to WebAssembly
2. Applies compatible obfuscation techniques that work within WebAssembly constraints
3. Ensures protected code passes WebAssembly validation

JavaScript Integration Layer

Shield secures the JavaScript-to-WebAssembly bridge:

• Protects interop method signatures
• Obfuscates JavaScript wrapper code
• Applies runtime verification checks

Working Within Binary Constraints

Since WebAssembly binary format has strict requirements, Shield:

• Preserves required export names while obfuscating internal functions
• Maintains valid WebAssembly module structure
• Ensures protected modules pass browser validation

Security Considerations in Browser Environments

JavaScript Tampering Protection

Shield provides protection against common JavaScript tampering techniques:

{
  "wasm": {
    "javascriptProtection": {
      "antiTampering": true,
      "antiDebug": true,
      "domIntegrityChecks": true
    }
  }
}

{
  "wasm": {
    "javascriptProtection": {
      "antiTampering": true,
      "antiDebug": true,
      "domIntegrityChecks": true
    }
  }
}

These settings add JavaScript-level protections that work alongside WebAssembly protections.

Network Security Integration

Shield can work with browser security features like Subresource Integrity (SRI):

{
  "wasm": {
    "enableSRI": true,
    "integrityVerification": true
  }
}

{
  "wasm": {
    "enableSRI": true,
    "integrityVerification": true
  }
}

This ensures your WebAssembly resources are loaded without modification.

Storage Security

Browser storage mechanisms (localStorage, IndexedDB) may contain sensitive data. Shield provides options to secure this data:

{
  "wasm": {
    "storageProtection": {
      "localStorage": true,
      "sessionStorage": true,
      "indexedDB": true
    }
  }
}

{
  "wasm": {
    "storageProtection": {
      "localStorage": true,
      "sessionStorage": true,
      "indexedDB": true
    }
  }
}

Working with Browser Developer Tools

Browser developer tools can inspect WebAssembly modules, presenting a challenge for protection. Shield addresses this with:

Debugging Prevention

Shield can detect when developer tools are open and take appropriate action:

{
  "wasm": {
    "devToolsDetection": {
      "enabled": true,
      "action": "warn" // Options: "warn", "obfuscate", "terminate"
    }
  }
}

{
  "wasm": {
    "devToolsDetection": {
      "enabled": true,
      "action": "warn" // Options: "warn", "obfuscate", "terminate"
    }
  }
}

Source Map Protection

For Blazor WebAssembly applications that use source maps:

{
  "wasm": {
    "sourceMapProtection": "remove" // Options: "remove", "obfuscate", "preserve"
  }
}

{
  "wasm": {
    "sourceMapProtection": "remove" // Options: "remove", "obfuscate", "preserve"
  }
}

Platform-Specific Considerations

Chrome & Edge

• Support for advanced WebAssembly features
• Developer tools can inspect WebAssembly code more thoroughly
• Shield applies additional protection layers for Chromium-based browsers

Firefox

• Different WebAssembly implementation with unique capabilities
• Shield optimizes protection for Firefox's specific architecture

Safari

• More restrictive WebAssembly implementation
• Shield ensures compatibility while maintaining strong protection

Mobile Browsers

• Limited developer tools
• Different performance characteristics
• Shield optimizes for mobile environments

Best Practices for Browser-based WebAssembly

1. Sensitive Logic Placement: Keep truly sensitive business logic on the server when possible
2. Defense in Depth: Use multiple protection layers including network security
3. Regular Updates: Keep Shield protection up to date as browser technologies evolve
4. Custom Verification: Add runtime integrity checks specific to your application
5. Testing: Test protected applications across multiple browsers and devices

For more information on WebAssembly-specific obfuscation techniques, see Obfuscation Strategy.