Documentation · Security
Security
Warden is intentionally powerful, so security is defined by server-side capabilities, filesystem validation and OS authority.
Threat model
Remote clients, forwarded headers, filenames, repositories, terminal streams, model/provider output and imported configuration are hostile inputs. Every API route is centrally classified as public, authenticated session, named capability or terminal WebSocket.
Implemented controls
- server-side accounts, identities, roles and capabilities;
- HttpOnly SameSite sessions and CSRF tokens;
- password throttling, optional TOTP and recovery codes;
- encrypted secret storage;
- origin and CSRF checks for terminal WebSockets;
- loopback-only proxy trust;
- filesystem confinement and atomic writes;
- typed administration and audit events.
Resource ceilings
Server enforcement caps outer HTTP bodies at 64 MiB and headers at 1 MiB. Narrower routes reduce that ceiling: file writes are 8 MiB, secure-backup imports 4 MiB, terminal frames 64 KiB and typed administration input/output 1 MiB. Accounts retain at most 32 browser sessions and 16 terminals; terminal scrollback is 256 KiB. Audit detail is 4 KiB with 100,000 retained events.
Git, system operations, provider exports, archive expansion, search results and undo history have independent time, count or byte limits. See the repository's docs/security/RESOURCE-LIMITS.md for the complete versioned inventory.
Frontend and accessibility boundary
API, provider, repository and filesystem strings are untrusted display data. Warden's HTML escaper is exercised with event-handler and markup payloads; the static gate rejects document.write, outerHTML, eval and dynamic function construction. Server authorization remains authoritative regardless of what a page displays.
The embedded dashboard provides a keyboard skip link, a visible high-contrast focus ring, polite status announcements and a reduced-motion mode that effectively disables animation and transition loops. Responsive layouts retain server-enforced capability and CSRF behavior at every viewport.
Reporting a vulnerability
Use the Warden repository's private GitHub security-advisory form. Include the affected version or commit, deployment topology, reproduction steps, expected and observed authority, and sanitized request IDs or logs. Never attach live credentials, recovery codes or private workspace content. The initial acknowledgement target is seven days; severity and coordinated disclosure timing follow reproduction.
HTTP limits
API bodies are capped at 64 MiB before handler-specific limits apply. Compressed request bodies are rejected, request headers are capped at 1 MiB, and API responses use Cache-Control: no-store. Security headers cover both successful and failed responses.
Proxy and WebSocket boundary
Forwarded headers are ignored unless proxy trust is enabled and the direct peer is loopback. Warden rejects ambiguous forwarded protocol chains, uses only the first proxy-supplied client hop, and requires terminal WebSocket origins to match both the effective request scheme and host. A terminal upgrade also needs the browser session, terminal.open capability and the session's CSRF token.
Files and archives
Filesystem API paths are resolved beneath WARDEN_FILE_ROOT. Copy and archive operations reject symlinks and special files. ZIP extraction rejects traversal, absolute paths, links, special files, more than 10,000 entries, more than 2 GiB expanded data and suspicious per-entry expansion ratios. Extraction is staged and atomically published into a new target, so Warden does not partially merge an untrusted archive into existing content.
Authority
Terminal and Agent processes run with the authority of the user that launched Warden.
Deployment
Keep Warden on loopback behind Caddy or nginx and use HTTPS. Follow exact campaign evidence on Battle Tested.