Webhood is designed around a simple principle: your scan data never leaves the infrastructure you control. Every screenshot, HTML snapshot, and network trace is stored in your own PocketBase volume. At the same time, the scanner component actively visits URLs submitted to it, including potentially malicious ones, which creates a distinct threat profile that any operator should understand before deploying Webhood in a shared or production environment.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/webhood-io/webhood/llms.txt
Use this file to discover all available pages before exploring further.
Data Ownership
All scan artifacts — screenshots, captured HTML, and trace files — are persisted inside the Docker volume mounted to the backend container. Nothing is transmitted to external services unless you explicitly configure a Cloud API integration. PocketBase acts as both the database and the file store, so a single named volume (data) contains the complete audit record of every scan your instance has ever performed.
Attack Surface
The scanner runs headless Chromium to render scan targets. A sufficiently malicious page can attempt to exploit the browser process itself. To limit the impact of such an attack, the scanner container is launched with a custom seccomp profile:files/chrome.json profile restricts the syscalls available to the container to only those required by Chrome, reducing the kernel attack surface. This also enables Chrome’s built-in sandbox without requiring the container to run as root.
Network Isolation
Webhood uses two separate Docker bridge networks to limit lateral movement between containers:- frontend — Kong, the core UI, and the backend share this network. The backend is reachable only from within this network; it has no publicly bound port.
- rest — Kong, the scanner, and the core UI share this network. The scanner communicates with the backend exclusively through Kong, which is the only bridge between the
restandfrontendnetworks.
Authentication Model
All API endpoints require a valid credential. Webhood supports three principal types, each with a distinct role:| Principal | Collection | Role field value | Can submit scans | Can access admin routes |
|---|---|---|---|---|
| Regular user | users | user | Yes | No |
| Admin user | users | admin | Yes | Yes |
| Scanner | api_tokens | scanner | Yes (internal) | No |
RequireCustomRoleAuth middleware enforces role separation at the route level: scanner tokens cannot call admin endpoints, and regular user tokens cannot call scanner-only routes. See Authentication for details.
SSRF Protection
WhenSCANNER_NO_PRIVATE_IPS=true is set, the scanner resolves the hostname of every submitted URL before visiting it and rejects the request if the resolved IP address falls within a private or loopback range. This prevents a class of server-side request forgery (SSRF) attacks where an attacker submits a URL that resolves to an internal service on your network.
TLS
Kong handles TLS termination. You provide a certificate and key via theWEBHOOD_TLS_CERT and WEBHOOD_TLS_KEY environment variables, which are mounted into the Kong container:
NODE_TLS_REJECT_UNAUTHORIZED=0, which applies only to its internal calls to the backend admin API — this does not affect TLS verification between your browser and the Kong proxy.