Server-side Sandboxing: An Introduction | Figma Blog (opens in new tab)

Server-side sandboxing helps contain the damage caused by vulnerabilities in software that processes untrusted user input. This is especially important for image processing, parsing, compression, and thumbnailing libraries often written in memory-unsafe languages, as demonstrated by ImageTragick. Figma argues that sandboxing complements—rather than replaces—secure coding by limiting a compromised workload’s access to data, services, and infrastructure.

Why Server-Side Sandboxing Matters

• Modern SaaS applications must process user-generated content using complex libraries.
• Many of these libraries are written in C or C++, which are vulnerable to memory-corruption bugs.
• ImageTragick showed how a vulnerability in ImageMagick could enable remote code execution when processing user-supplied images.
• Preventing every vulnerability through rewrites, memory-safe languages, or program analysis is expensive and imperfect.
• Sandboxing provides defense in depth by containing failures when vulnerabilities are exploited.

Figma’s Server-Side Risk

• Figma uses server-side components such as RenderServer, a C++ version of the editor, along with third-party libraries for graphical data.
• Malicious input processed directly inside production infrastructure could allow an attacker to:
  • Access data belonging to other jobs
  • Make requests to internal production services
  • Move laterally through the environment
  • Compromise additional systems
• Sandboxing reduces the external interfaces and resources available to potentially compromised workloads.

Common Sandboxing Approaches

• The article introduces three major sandboxing primitives:
  • Virtual machines (VMs): Isolate workloads through a hypervisor and separate guest operating systems.
  • Containers: Isolate workloads using operating-system-level mechanisms and container engines.
  • Seccomp: Restricts the system calls a program is permitted to make.
• Each approach involves trade-offs in security properties, operational complexity, performance, and suitability for different workloads.
• The article’s broader goal is to help teams compare these options and select an appropriate combination of isolation techniques.

Choosing an Appropriate Strategy

• Sandboxing technologies have historically been expensive, immature, or difficult to operate at scale.
• Recent improvements have made virtualization, containment, and workload isolation more practical for a wider range of security teams.
• Teams should evaluate sandboxing based on their workload’s risk, required interfaces, resource needs, and acceptable operational trade-offs.

Teams should treat sandboxing as a practical layer of defense around risky processing workloads, rather than relying solely on preventing vulnerabilities.