Docs

Trust, Governance & Security · 09.11

Outbound & Network Safety

SSRF protection on every outbound call, secrets resolved from the vault at call time, and rate limiting plus security headers at the edge.

Network safety

Consolidated view: what protects an outbound call

Full mechanics of the SSRF guard — checked after DNS resolution specifically to close the DNS-rebinding gap, the exact private ranges it blocks including the cloud metadata endpoint — live in Reach: Outbound Safety, since that's where the guard actually gets exercised, on every connector and integration call. This page is the security-surface summary: connector secrets are resolved from the vault only at the moment of the call and are never written into the workflow graph itself, so a graph export or a shared workspace bundle can never accidentally carry a live credential inside it.

The edge layer: rate limiting and security headers

An in-memory token-bucket rate limiter protects sensitive endpoints like login, deliberately documented as not cluster-safe — a genuinely multi-process or high-availability deployment needs to front it with a real distributed limiter (Redis-backed, or an edge throttle) rather than relying on this in-process bucket alone. Security headers are applied globally to every response: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a Content-Security-Policy restricting scripts and connections to 'self', Referrer-Policy: no-referrer, locked-down Cross-Origin-Opener/Resource-Policy, a Permissions-Policy denying camera/microphone/geolocation outright, and Strict-Transport-Security gated to production only (so local development over plain http://localhost is never poisoned by HSTS). The API's own self-hosted docs (/v1/openapi.json, /v1/docs) are deliberately carved out from the strict CSP — Scalar's documentation UI needs looser rules than the operator console itself does.

Continue