As per the official website of WebAssembly.org, which is available at https://webassembly.org/docs/security/ the main goal of WebAssembly in terms of security is as follows −

The security model of WebAssembly has two important goals −

• Protect users from buggy or malicious modules, and

• Provide developers with useful primitives and mitigations for developing safe applications, within the constraints of (1).

The compiled code i.e. WASM from C/C++/Rust is not directly executed inside the browser and makes use of Javascript API”s. The WASM code is sandboxed i.e. executed through Javascript API wrapper and the browser talks to WASM using the API.

Here, is an example of using a .wasm file inside the browser.

Example − C Program

#include<stdio.h> 
int square(int n) { 
   return n*n; 
}

We will make use of WASM explorer to get the wasm code −

Download WASM code and use it to test the api’s.

Example

<script type="text/javascript"> 
   const importObj = {
      module: {}
   }; 
   fetch("findsquare.wasm")      
      .then(bytes => bytes.arrayBuffer())          
      .then(module => WebAssembly.instantiate(module,importObj))                 
      .then(finalcode => {
         
      console.log(finalcode); console.log(finalcode.instance.exports.square(25)); 
   }); 
</script>

Output

You will get the following output −

The exports objects have a reference to the function to be called. To call the function square, you will have to do it as follows −

console.log(finalcode.instance.exports.square(25));

Issues with WASM compiled code

Following are the issues with WASM compiled code −

• It is difficult to check, if there is any malicious code being inserted, while compiling the code to wasm. There are no tools available at this moment to validate the code.

• Wasm is difficult to analyse and the buggy/malicious code can be easily executed inside the browser.