Check out how WebAssembly (WASM) portability and security models work in this beginner’s guide.
Both are advanced WebAssembly (WASM) topics. We recommend you read the previous two topics in our WebAssembly for Beginner series.
- WebAssembly for Beginners – Part 1: An Introduction To WASM
- WebAssembly for Beginners – Part 2: Goals, Key Concepts, and Use Cases
Let’s get started.
WebAssembly’s portability makes it ready for the Web. In fact, you can define WASM as a portable sandboxed platform.
Furthermore, its binary format enables it to execute across various instruction set architectures and operating systems. This means you can use WASM not only on the Web but also off the Web.
To understand WASM portability, we’ll discuss the following:
- Local, limited, and nondeterministic environment.
- Specific execution environment characteristics
- WASM web and non-web portability
Local, Limited, and Nondeterministic
WASM needs an efficient execution and proper environments that are local, limited, and nondeterminism. Nondeterminism is computing that specifies that an algorithm/compiler/environment outputs different behaviors or results even for the same input. It is the opposite of a deterministic algorithm.
The two other aspects, limited and local, are associated with nondeterministic execution. To make nondeterministic execution work, you need well-defined use cases which are “limited.”
Also, these executions are “local” with no effect outside the environment. Read their official nondeterminism in the WebAssembly doc to learn more about it.
Specific Execution Environment Characteristics
To make WebAssembly portable, it assumes that the execution environment offers the following characteristics:
- Byte memory granularity addressability and 8-bit bytes.
- 32-bit two’s complement signed integers. Optionally 64 bits.
- Software emulation is possible via unaligned memory accesses or reliable trapping.
- Support for 32-bit and 64-bit floating points as defined in IEEE 754-2008.
- Guarantee to execute all threads with forward progress.
- For 64-bit access, wasm64 should provide lock-free atomic memory operators.
- The lock-free atomic memory operators include 8, 16, and 32-bit accesses.
- wasm64 support linear memory higher than 4 GiB with 64-bit indices or pointers.
- Little-endian byte ordering.
All major browsers, including Chrome, Edge, Firefox, and WebKit, support all these environmental requirements.
Moreover, WebAssembly is evolving at a rapid pace. The WASM Community Group and W3C WebAssembly Working Group are working towards its standardization. That means any of these requirements can change in the future.
WASM Web and Non-Web Portability
WebAssembly’s primary purpose is to provide portability and native performance on the Web and the non-web. In this section, we’ll look at how WASM achieves it.
#1. Web Embedding
WASM integrates well with the Web ecosystem, including the Web’s security model, web portability, and web APIs. Moreover, it must have enough room for creative development down the road (read WebAssembly for Beginners – Part 2 to understand its goals)
To learn more about how WASM achieves high-level Web compatibility, read this: Web Embedding – WebAssembly.
#2. Non-Web Embedding
As mentioned earlier, WASM also works with non-web environments. As a developer or business, you can create high-performance applications or write sections of your app that need performance tuning. For example, you can use it on IoT devices, data center servers, and desktop/mobile apps.
To learn more, read Non-Web Embeddings – WebAssembly.
WebAssembly is a binary format solution that offers native-like performance. It works great on the Web but can also be fine-tuned to work on non-web embeddings. This makes WASM widely available across services, solutions, and processes. However, this means more security challenges.
WASM Security Challenges and Risks
Even though WebAssembly is considered safe and efficient, it comes with multiple security risks, including:
- WebAssembly sandbox
- Memory management
- Code obfuscation
- Integrity checks
#1. WebAssembly Sandbox
#2. Memory Management
Memory Management in WASM is tricky. Firstly, it doesn’t directly access physical memory as it executes within VM. That’s why it uses the host machine’s memory.
#3. Code Obfuscation
WASM’s sandbox execution makes its code obfuscated. Additionally, the WASM binary format is also not human-readable, making it hard to reverse engineering, which is necessary to identify malicious code.
These make WebAssembly code hard to debug due to its lack of human-readable format. This opens up many security loopholes, including hackers‘ ability to hide code that steals sensitive information or does code injection to take over the host machine.
#4. Integrity Checks
Any data transferred through the Web is vulnerable to data tempering. For example, hackers can perform a man-in-the-middle attack to change data values. It is an issue for WASM, considering it has no proper way to do integrity checks.
Understanding WASM Security Model
WebAssembly takes security seriously. That’s why, on the official WASM docs, they have mentioned that their security model takes care of two important goals:
- Ensure that no buggy or malicious modules affect users
- Ensure that developers can mitigate any security risks and create safe applications while ensuring that point 1 is always maintained.
The WASM security model knows WebAssembly apps execute independently while not being able to escape its sandbox environment. However, APIs can open up a way to attack the host environment.
Another fault-tolerant technique includes executing apps deterministically with limited expectations. By ensuring both conditions, most app executions are deemed safe.
To improve security, developers should enforce the same-origin policy for information flow. If you’re developing for non-web, you must use the POSIX security model. If you want to read more about its security model, check out: Security – WebAssembly.
The WebAssembly System Interface(WASI)
WASI (The WebAssembly System Interface) also plays a crucial role in WASM non-web embedding as it improves security. It is a modular system interface that offers exciting security characteristics and portability.
In fact, it is now part of the WebAssembly System Interface Subgroup Charter and hence standardized. Due to WASI, WASM is widely adopted in different edge/server computing areas. Also, WASI simplifies security when moving to a non-web embedding from a web-embedding environment.
WebAssembly’s portability and security are two big topics. In part 3 of the WebAssembly for beginners, we tried to simplify it and break it down, especially for beginners.