Skip to content

Security: muizidn/NetworkSpy

Security

SECURITY.md

🛡️ Security Architecture

Network Spy is designed with a local-first security model. We believe that your network traffic is sensitive, and you should have complete control over it. This document outlines the security architecture of Network Spy, including how we handle data, SSL decryption, and the security implications of custom features like the Custom Viewer Engine.


1. Local-First Data Storage

  • Zero Cloud Reliance: All captured traffic, session logs, filters, and custom viewers are stored locally on your machine in a high-speed SQLite database.
  • No Data Exfiltration: Network Spy does not send your captured traffic to any external servers for analysis. All processing happens locally.
  • Telemetry & Error Tracking: We use PostHog for product analytics and Sentry for crash reporting. These tools help us improve the app and fix bugs. They only track anonymized usage metrics (such as feature interactions and page views) and error stack traces. They never collect or include captured payload data, intercepted traffic, or any sensitive personal information.

2. SSL Decryption & Root CA

To inspect HTTPS traffic, Network Spy acts as a Man-in-the-Middle (MITM) proxy.

  • Unique Root CA: When you enable HTTPS decryption, Network Spy generates a unique Root Certificate Authority (CA) on your machine.
  • On-the-Fly Certificates: This CA is used to generate SSL certificates on the fly for the domains you are intercepting.
  • Security Best Practices:
    • The private key for your Root CA is stored securely on your local machine.
    • It is never shared with us or any third party.
    • You should treat your Root CA with care. Do not share it, as anyone with access to it could potentially intercept your traffic if they are on the same network.

3. Custom Viewer Security 🎨

The Custom Viewer Engine is a powerful feature that allows users to create specialized visualizers using custom JavaScript. Because this feature allows code execution, it requires careful handling.

How It Works Under the Hood

Custom viewers use the new Function constructor in JavaScript to execute user-defined logic. The app passes the request and response context (headers, body) to this function, which then returns data to be rendered on the canvas.

Security Implications & Risks

  • Arbitrary Code Execution: Custom viewers can execute arbitrary JavaScript within the context of the app's frontend.
  • Access to Tauri APIs: Network Spy is built on Tauri. While Tauri restricts access to system resources by default, the app requires certain permissions to function (e.g., reading/writing files in $DOCUMENT and $APPDATA directories). A malicious custom viewer could potentially attempt to use these APIs to read or modify files within those scoped directories.
  • XSS (Cross-Site Scripting): If a custom viewer renders HTML unsafely (e.g., using the html block type without proper sanitization), it could be vulnerable to XSS.

How to Stay Safe

  1. Trust the Source: Only run custom viewers that you have created yourself or that come from a trusted source.
  2. Review Code: If you import a custom viewer from the community, always review the code in the builder before applying it to your traffic. Look for suspicious external fetch requests or file system operations.
  3. AI Generation: Viewers generated by the built-in AI (Pro feature) are designed to be safe and focused on data mapping, but it is still good practice to review them.

4. Tauri Security Sandbox

Network Spy leverages the security features provided by the Tauri framework:

  • No Node.js Runtime: Unlike Electron, Tauri does not expose a Node.js runtime to the frontend, significantly reducing the attack surface for remote code execution.
  • Scoped File System: Access to the file system is strictly scoped to specific directories needed for operation (e.g., $DOCUMENT for exports and $APPDATA for configuration). The app cannot access arbitrary files on your system without explicit permission.
  • Isolation Pattern: Tauri provides an isolation pattern to prevent malicious frontend code from accessing the backend directly, ensuring a secure bridge between the webview and the Rust core.

There aren't any published security advisories