Sandboxing
Also known as: security sandbox, application sandboxing, malware sandbox
Sandboxing is a security technique that runs a program, file, or piece of code in an isolated, restricted environment, so it can't affect the rest of the device or network.
Web browsers sandbox every website, phones sandbox each app, and email security tools 'detonate' suspicious attachments in a sandbox to see what they do. While sandboxing is a powerful safety net, attackers look for 'sandbox escapes' and some malware detects sandboxes and behaves innocently.
Sandboxing, explained at three levels
At home
A sandbox is like a playpen for programs. Whatever happens inside stays inside, so a bad program can't mess with the rest of your computer.
At work
Sandboxing lets organizations safely open suspicious files and limits damage if an app is compromised.
At home
Your phone keeps each app in its own sandbox, which is why one app can't read another app's data without permission. Your browser does the same with each website.
At work
Email and web gateways run attachments and links in sandboxes to observe behaviour before delivery. Developers use containers and virtual machines as sandboxes for testing. Windows Sandbox provides a disposable desktop for trying risky files.
At home
The most expensive attacks need a 'sandbox escape,' which is why exploits for phones and browsers cost so much. In my opinion, that's a sign sandboxing is working.
At work
Limitations include evasive malware that checks for virtual environments, delays, or user interaction; performance costs; and escape vulnerabilities. Combine sandbox analysis with EDR, and keep sandbox platforms patched, since escapes are high-value targets.
Real-world examples
At home
Nadia received a strange document from an unknown sender. She opened it in Windows Sandbox, and when it tried to download a program, she simply closed the sandbox, erasing everything.
At work
Jerome runs email security for a Vancouver credit union. Their gateway sandboxes every attachment for a few seconds before delivery, catching malware disguised as invoices.
How it compares
| feature | Sandboxing | Antivirus signatures |
|---|---|---|
| Approach | Isolate and observe | Match known threats |
| New, unknown threats | Can catch by behaviour | Often missed |
| Speed | Slower, needs analysis time | Fast |
| Evasion | Some malware detects sandboxes | Changing code evades signatures |
Signatures catch known threats. Sandboxes reveal unknown ones by watching behaviour.
For analysts
I'd make sure email security includes attachment sandboxing. It's a quiet control that stops many threats before staff ever see them.
History & origin
The idea of restricting untrusted code grew in the 1990s; Java applets, introduced in 1995, ran in a 'sandbox' that limited what web-delivered code could do. Researchers at UC Berkeley described sandboxing for untrusted helper applications in 1996. Google Chrome launched in 2008 with each tab running in its own sandboxed process, a design other browsers adopted. Apple's iPhone sandboxed every third-party app from the App Store's launch in 2008. Security vendors such as FireEye built businesses around sandboxing suspicious files in the 2010s, and Microsoft added Windows Sandbox in 2019. In my view, sandboxing is the reason most drive-by browser attacks fail today.