Image via Shutterstock 

WebAssembly is surging in popularity — a recent Cloud Native Computing Foundation survey found that 37% of organizations have already deployed applications leveraging the technology. As more and more organizations find uses for it, some basic principles at its core provide a key level of security.

Cosmonic CEO Liam Randall told The New Stack that it makes sense to see WebAssembly as the world’s smallest virtual machine. “Think of it just like a little CPU,” he said. “It is very secure in that it uses sandboxed memory, and it uses deny-by-default capabilities.”

Deny-by-default, Randall said, is a significant differentiator. “This is the opposite approach of containers, where you start wide open and then you need to go back and close everything down from there,” he said. “Here, you start with everything shut off in every application.”

Think of it like being asked to grant permission for your browser to access your mic and camera for a video call. “Your WebAssembly process can’t access any files or folders or devices without being explicitly granted permission to do so… so before you run an application, you can understand what capabilities it has and understand the impacts of running it,” Randall said.

Maintaining Control

InfinyOn founder and CTO Sehyo Chang told The New Stack that his company’s Fluvio data streaming platform depends on that level of sandboxing to maximize security. “The way it works is that it doesn’t make any system calls… so we can make sure that it doesn’t cause any damage,” he said.

And even as InfinyOn explores enabling additional functionality, Chang said, it can continue to maintain control as it does so. “Instead of making arbitrary HTTP calls, maybe we sandbox and make it so [that] only a certain set of HTTP calls are allowed – it doesn’t have to be like the Wild West,” he said.

Still, Chang said, it’s important to keep in mind that WebAssembly doesn’t inherently guarantee security. “We still have to make sure the code is secure, make sure dependencies are locked down – that doesn’t go away,” he said. “It’s just that with WebAssembly, there’s less chance of that causing security vulnerabilities.”

So for developers, all the standard precautions still make sense. “Just because you introduce a new kind of tool, that doesn’t skip all the checklists you’ve done before… it just means that with WebAssembly, you have a good foundation and more ways to leverage it,” Chang said.

Supporting APIs

Fermyon CEO Matt Butcher said that’s where WASI, the WebAssembly System Interface, comes in. “The WASI proposal was born out of the desire to build a way for a WebAssembly module to say, ‘I want to do things like access something that looks like a file, access something like looks like an environment variable, access something that looks like the system clock or the random number generator.'”

“The point of WASI is to give a lot of guidance on that, and say, ‘This is how it should work, this is what you want to be aware of, and here’s the APIs that we’re going to use,'” Butcher said.

Still, the specifics remain up to the host runtime. “A runtime could give it access to the file system, or give it restricted access to a set of pre-opened files, or fake a file system in memory, or really do whatever it wanted — it’s just a matter of saying, ‘I’m presenting you [with] a thing that to you looks like a file system,'” Butcher said.

In most cases, then, while functionality increases, the system remains secure. “The way Fermyon, for example, implemented the file system interface, you’re never really reaching down into the file system — you’re always getting an in-memory clone of the file system,” Butcher said.

Assessing Runtimes

While different WebAssembly runtimes have different strengths, many provide additional enhancements to security. “The Bytecode Alliance’s Wasmtime provides a sandbox, you get isolated linear memory, you get buffer overflow prevention, and the module cannot be modified at runtime,” Randall said. “So the runtimes themselves give you a ton of basic uplift from a security perspective.”

Over time, Butcher suggested, the range of WebAssembly runtimes will likely narrow and the ones most closely focused on security will survive. “That’s one of the reasons why Fermyon has said that Wasmtime, being governed by a community with big players in it like Red Hat and Microsoft and Google and Amazon, all of who care deeply about the security model, is a safer bet for us than, say, writing our own WebAssembly interpreter — which we could have done on a technical level, but then all of that becomes our responsibility,” he said.

All of those eyes on Wasmtime come with an inherent benefit. Butcher pointed to a recent post by Frank Denis that suggested Wasmtime’s disclosure of several vulnerabilities over the past year is actually a good sign, rather than a cause for concern. “As Frank expressed, we should rightly be skeptical when a WebAssembly runtime is not announcing security vulnerabilities, because on one hand, they may be really, really good — but on the other hand, they may just not care about security as much,” he said.

Maintaining Security

Ultimately, Randall said, WebAssembly offers developers a significantly higher security bar than previous technologies. “It is somewhat of a break from the past, and it starts with first principals like deny-by-default by design,” he said. “Those things make WebAssembly incredibly more secure as a starting point for development.”

And Butcher said there’s no reason to think WebAssembly can’t remain a hardened system. “The thing is, the number one way to break that is to start poking holes in the sandbox… and this is why I think the WASI standard has moved very slowly, and why the people who have been behind WASI have endorsed a process that is slower and more careful,” he said.

That caution, Butcher said, is key. “The original one was very, very secure, much stronger than the JavaScript security sandbox because there was nothing the guest module could do,” he said. “We want to move it just far enough to the right where we can do the things we really need to do as developers… but not at the risk of opening up too much of an attack surface.”

Jeff Goldman is a Los Angeles-based technology journalist.

Read more from Jeff Goldman