Security

Dashboard access

The dashboard is protected by the configured username and password, but it is still served by your application. Keep it on a private development network and avoid exposing /_devtools to the public internet.

Encryption at rest

The optional encryption service protects configured field names in supported request/response metadata, current-user metadata, and outbound HTTP detail records in the local SQLite database with AES-256-GCM. It is not a blanket database-encryption policy and it is not redaction: authenticated dashboard/API reads decrypt covered values. Other span attributes and fields not selected for encryption remain plaintext.

Header redaction

Header redaction is enabled by default for captured HTTP details and matching HTTP header span attributes. The default sensitive names are authorization, proxy-authorization, cookie, set-cookie, and x-api-key.

redaction: {
  additionalHeaders: ["x-access-token", "client-secret"],
}

Additional names extend the defaults. Names are trimmed, matched case-insensitively, and de-duplicated. Redaction occurs before persistence or encryption for covered paths. It does not currently redact bodies, URL/query values, or arbitrary non-header span attributes, and existing stored records are not rewritten.

Sensitive data

Request and response bodies, URLs/query parameters, headers, database statements/arguments, Redis commands/arguments, exceptions, stack traces, and user context can contain secrets or personal data. Capture is conditional on instrumentation, request context, parsers, configured hooks, and driver load order. Use local credentials, a secure environment-variable store, and a deliberately chosen fields list. Do not commit server-devtools.db or real secrets.

Storage and overhead

The built-in storage provider is SQLite at ./server-devtools.db, relative to the process working directory. Database and Redis instrumentation are capture sources, not telemetry storage providers. The SDK does not send telemetry to an external collector or ServerDevTools service. Clear History and trace deletion remove stored trace data; no trace TTL is implemented. Dashboard sessions are separate, use hashed tokens, expire after 24 hours, and are removed on logout or expired-session cleanup.

Native outbound request and response body capture has an independent 256 KiB byte limit: oversized bodies are skipped rather than truncated, while complete network bytes still reach the destination/application. Inbound response and fetch capture do not currently use that SDK byte limit. Body buffering, fetch cloning, span mapping, optional encryption, and persistence add work and memory use; no zero-overhead claim is supported by a benchmark.