DTNDailyToolNest

Security Architecture

DailyToolNest is engineered with structural defense-in-depth guarantees. Privacy is not a marketing slogan; it is an architectural contract enforced by origin boundaries, browser security primitives, and container sandboxing.

1. The Two-Origin Domain Model

Web applications that mix static client-side processing with server uploads under a single domain risk accidental egress, script injection, and CSRF token leakage. DailyToolNest enforces physical separation across two origins:

  • Main Origin (dailytoolnest.com): Next.js App Router. Serves marketing, documentation, guides, and Normal-mode server processing.
  • Device Origin (device.dailytoolnest.com): Static Vite-built application. Serves Sensitive mode. Contains zero server-side rendering, zero API endpoints, and zero backend state.

2. Content Security Policy (Device Origin)

The device origin enforces a restrictive Content Security Policy headers on every response:

default-src 'none';
script-src 'self' 'wasm-unsafe-eval';
style-src 'self';
img-src 'self' blob: data:;
font-src 'self';
connect-src 'self';
worker-src 'self' blob:;
frame-ancestors 'none';
base-uri 'none';
form-action 'none';

Notice that connect-src 'self' only permits fetching relative static chunks and WASM artifacts. Any attempt to exfiltrate bytes to an external endpoint is immediately aborted by the browser engine.

3. Server Sandbox (Normal Mode)

When files are submitted to the server for Normal processing:

  • Uploads require explicit confirmation of server processing.
  • Files are encrypted in transit via TLS 1.3 and at rest with authenticated AES-256-GCM.
  • Processing tasks execute in isolated containers with gVisor kernel sandboxing.
  • Containers operate with zero internet routing (egress disabled).
  • Closing the page shreds the job immediately. Downloading it starts a five-minute window, which is never extended by downloading again. An automated sweeper purges anything still left fifteen minutes after processing finishes; time waiting in the queue does not count.

4. Open Verification and Reproducible Builds

All client-side WebAssembly engines are compiled from open-source libraries (e.g. qpdf, libheif, jSquash). Build hashes and third-party software bills of materials (SBOM) are published in /.well-known/dtn-build.json for independent security audit.