If you haven’t already heard about WebAssembly (WASM), you likely will soon. An open, industry-wide effort to bring a safe and efficient assembly-like language to the internet, WASM technology is a collaborative effort between major browser vendors, including Google, Microsoft, and Apple, as well as non-browser web technology companies. WebAssembly’s use of sandboxing helps mitigate security risks from its execution semantics while maintaining compatibility with programs written for C, C++, and other high-level programming languages.

To understand why WASM was created, it’s helpful to talk about the history of code in web development. In the beginning, JavaScript was the gold standard — and it was widely adopted among developers because of its ease of use; It was a developer-friendly technology. Early JavaScript implementations initially parsed the code, then executed the code, and collected the garbage. The execution phase took a lot of time.

As the web grew and code became more complicated, developers needed to find a way to increase the speed of loading code that renders websites and their content. Remember the days of getting a cup of coffee while a web page loaded on your screen? That was brutal. To compensate for the slowness of JavaScript, browsers developed faster JavaScript engines to increase code execution speed.

At this point, the concept of “just in time” compiling was introduced, optimizing and compiling frequently used and repeated code. The above three steps now grew to five: parse, compile and optimize, reoptimize, execute, and collect garbage. The result? Improved execution speed, but some thought it could be even faster.

What WASM is and isn’t

The final piece of the puzzle to improve speed was the optimization step. WASM adds technology that eliminates the need to reoptimize and compacts the steps: decode, compile, and optimize, and execute. Along with this increase in execution in speed, WebAssembly is also:

1. Portable: The same code can be run in different devices within browsers, servers, or even IOT devices

2. Modular: Particularly compute-heavy tasks can be delegated to WebAssembly, therefore also limiting what functions must be imported into these modules

3. Compiled from high-level languages: Because developers can write in C, C++, Rust, Python, or Ruby, native code can be run within a browser

4. Sandboxed: WebAssembly modules are executed within a sandboxed environment separated from host runtime using fault isolation techniques

Now that we know what WASM IS, let’s clarify what it ISN’T:

1. WASM != A replacement of JavaScript. Rather, WASM and JavaScript will work hand in hand, creating faster, portable bytecode

2. WASM != Assembly language.WASM isn’t a low-level assembly language as the name might suggest. It’s a machine language for a conceptual machine, not for an actual physical machine.

3 components of WebAssembly

WebAssembly is comprised of three basic components. Basic familiarity with these components will help you understand the code example that follows:

· Linear memory: A contiguous memory space with pointers that range from 0 to maximum memory. The address spaces are 32-bit sized, and unlike native stack, it does not have any page protection, which means that all memory is always writeable. There is no memory that is constant or nonwritable.

· Function table: Every function is mapped against an index in this table. Function calls do not happen to arbitrary addresses. For example, if function 3 is called, then the address of function 3 is looked up in the function table to execute the function.

· The stack: A push or pop of values exists in the stack for every operation done in a webAssembly module.

An example

If you are interested in seeing what some sample code looks like, I’ve created a short example of how you can call WASM from JavaScript. You can find it in this Github repo.

It’s basically four simple steps:

1. Go to https://webassembly.studio/

2. Create an empty C project

3. Add and save the C, JS and html code from the git repo to your project

4. Build and run your project https://webassembly.studio/

What about security?

WebAssembly modules execute within a sandbox, which means that they can’t access memory or resources outside of the sandbox unless they are directly given access. This also means that the application will execute in a deterministic way except in some cases, such as different compiler versions.

It’s also important to note that WebAssembly adheres to the security policies of the environment in which it is embedded. For example, if the WebAssembly module is embedded within a browser, it follows the same origin policy.

Because WebAssembly is compiled from other high-level programming languages,

vulnerabilities in those languages can migrate over to WebAssembly as well. For example, a buffer overflow from a strcpy() in C++ into a buffer with less space than needed will be present in the compiled WebAssembly code as well.

For native applications, we have several traditional security bandages that protect the native stacks, such as stack canaries, page protection, ASLR, virtual memory, and control flow integrity. But the question comes up if these bandages exist in WebAssembly? Do we even need them? We will talk more about this topic, how we are using WASM here at Adobe, more best practices, and additional security considerations for WASM applications in future blog posts.