How to Sandbox Python: Run Untrusted Code Safely (Tested)

The classic idea: run the user's code with the builtins removed, so they can't call open, __import__, or eval. It looks airtight — and it's defeated by a single expression, because Python's introspection lets you climb from *any* object back to every class loaded in the process:

# a naive "sandbox": strip every builtin, then run the user's code
SANDBOX = {"__builtins__": {}}

# the attacker submits this — it uses NO builtins, only introspection:
escape = (
    "[c for c in ().__class__.__base__.__subclasses__() "
    "if c.__name__=='BuiltinImporter'][0]().load_module('os')"
    ".system('echo ESCAPED-THE-SANDBOX')"
)
eval(escape, SANDBOX)

ESCAPED-THE-SANDBOX          # os.system executed — sandbox defeated

# it's not subtle: from an "empty" sandbox you still reach every
# class loaded in the interpreter —
>>> len(eval("().__class__.__base__.__subclasses__()", {"__builtins__": {}}))
177

().__class__ is tuple, .__base__ is object, and object.__subclasses__() lists every class in the process — including one that can import os. From there it's os.system, and the attacker owns your machine. No builtins required.

The most mature language-level option is RestrictedPython (from the Zope project). Instead of a blocklist, it compiles a *restricted subset* of Python and refuses dangerous constructs — including the dunder-attribute access the escape above depends on:

from RestrictedPython import compile_restricted, safe_globals

src = "().__class__.__base__.__subclasses__()"   # the escape from above
bytecode = compile_restricted(src, "<user>", "eval")
eval(bytecode, dict(safe_globals))

SyntaxError: Line 1: "__subclasses__" is an invalid attribute name
            because it starts with "_".
# RestrictedPython refuses dunder access at COMPILE time — escape blocked.

If a server has to execute genuinely untrusted code, the real boundary is the operating system, not the language. In rough order of strength:

• Containers (Docker/Podman) — Linux namespaces (PID, network, mount) isolate the process. Good, but a container shares the host kernel, so a kernel exploit escapes it. Drop capabilities, use a read-only rootfs, and disable networking.
• `seccomp` — a kernel feature that restricts which system calls a process may make (in the strictest mode, essentially only read, write, exit, sigreturn). Layer it on top of a container to shrink the attack surface.
• gVisor — a user-space kernel that intercepts syscalls, adding a strong isolation layer between the code and the real kernel.
• Micro-VMs (Firecracker) — a real VM boundary with near-native speed and millisecond boot. This is what serverless platforms use to run arbitrary customer code safely.

The modern sweet spot is WebAssembly. Python compiled to WASM (via Pyodide) runs inside a sandbox that was *designed* for untrusted code from day one and hardened in browsers for a decade. By default a WASM module has no filesystem, no network sockets, no environment variables, and no OS access — it can only touch what the host explicitly hands it.

That flips the escape from the first section on its head: even if attacker code reaches os inside a WASM Python, os.system has nothing to call — there's no shell, no real filesystem, and socket can't open a connection, because the WASM runtime simply doesn't expose them. The isolation is enforced *below* Python, so Python's dynamism can't defeat it.

Our free online Python compiler is a WASM sandbox — it runs your code through Pyodide entirely in your browser tab. That gives you the isolation properties above with zero setup:

• Nothing runs on a server — the code executes in *your* browser, so there's no backend to attack and nothing is uploaded.
• No sockets, no real filesystem, no OS — a reverse shell or credential-stealer simply can't function; the APIs it needs aren't there.
• It even installs packages — import auto-installs pure-Python wheels from PyPI via micropip, still inside the sandbox.

Short version: never trust a restricted eval. For a trusted subset, RestrictedPython. For a server running hostile code, containers or micro-VMs. And for running untrusted Python right now with nothing to install, a WASM sandbox like our in-browser compiler is the fastest safe path.