Untrusted code execution is the process of running software that cannot be assumed to execute correctly (bug-freedom) or with good intentions (malware-freedom). Today, untrusted code execution is found in various places, from a web-browser safely running websites on a mobile phone, to a large cloud computing provider running customer workloads on managed hardware and infrastructure. From an operating system perspective, we talk about sandboxing or isolation of user code. Computers typically solve this through virtualization, which one can view as the most uniquely characterizing ability of computers in general. Various different approaches exist to virtualize workloads that cannot be fully trusted, with varying levels of distrust. Sandboxing fully untrusted code requires precise control over the capabilities of the untrusted workload (can it access the network? the file system? can it make syscalls?), minimizing the attack surface for malicious code. This is commonly achieved through all kinds of virtual machines. Unfortunately, VMs often pose a tradeoff between security and efficiency. Running fully untrusted workloads inside a virtualized operating system may yield good security and generality, but typically comes at high cost due to inefficient resource utilization. This work explores the use of WebAssembly to implement extremely lightweigt, general purpose sandboxing, by implementing WebAssembly execution engines for the Dandelion cloud platform. WebAssembly is a binary instruction format supported as compiler target by many programming language compilers today. It aims to allow execution in a highly controlled environment with little performance penalty compared to native machine code. We show two different approaches of integrating WebAssembly into a server-side environment like Dandelion. We discuss the tradeoffs between them, and quantify them in a comprehensive evaluation. We compare the approaches against each other, as well as against other lightweight VM-less sandboxing mechanisms in Dandelion. Within two different testing setups, under varying computational demand, we find that the two Wasm approaches complement each other well. In each of our tests, at least one of the Wasm approaches performs either on-par with, and sometimes significantly better than the fastest alternative. Furthermore, both Wasm approaches are highly independent of the underlying hardware. These findings illustrate the potential for WebAssembly as a general-purpose software sandboxing technology. Finally, some further thoughts and possible directions for future research are discussed.