Security

MockBase runs code you configure (templates), makes network calls on your behalf (Record & Replay), and stores traffic that can carry credentials (Request Inspector). Here's what protects each of those, in one place.

Authenticating to a mock

Anyone who has a mock's id can call it unless you turn on Token Protection. Once enabled, every request needs a valid Authorization: Bearer <token> or X-Mock-Token header — MockBase stores only a SHA-256 hash of the token, never the plaintext, and shows you the real value exactly once, at creation or rotation. Verifying a presented token uses a constant-time comparison, so a wrong guess can't be narrowed down by how long the check takes.

This is separate from your MockBase account login (email/GitHub) — token protection guards one mock's public endpoint, not your dashboard.

Response header safety

Route response headers you configure are validated before they're ever stored: header names must look like real header tokens, and values can't contain carriage-return or line-feed characters — the classic way a malicious value could inject a second, unintended header or split the response. Every mocked response also gets Cache-Control: no-store forced onto it server-side regardless of what you set, so a browser never caches a stale 404 or an old status after you've reconfigured a route.

Record & Replay and outbound requests

Record & Replay is the one feature where MockBase makes a real network call for you, so it's the one place SSRF matters. Before proxying, MockBase resolves the target hostname and refuses to connect if any resolved address is private, loopback, link-local, multicast, or otherwise non-public — so a target URL can't be used to reach your own internal network through MockBase's servers. Redirects from the target are never followed, and hop-by-hop headers (Host, Connection, Transfer-Encoding, proxy-auth headers, etc.) are stripped from both the outbound request and the captured response before anything is stored or replayed back to you.

This check happens at request time, not once when you set the URL, so it can't be bypassed by pointing at a domain that only resolves to an internal address after the fact — though, like any DNS-based check, it can't fully rule out a target that changes what it resolves to between the check and the actual connection.

What shows up in the Request Inspector

The Request Inspector streams real traffic, including whatever headers and bodies your app actually sends — so before it's stored or streamed anywhere, MockBase redacts Authorization, X-Mock-Token, Cookie, and Proxy-Authorization to [redacted]. That protects you from leaking a live token into your own inspector, but it also means you won't see the real value there if you're debugging exactly what your app sent — check your app's own outgoing request logs for that.

Templates run sandboxed

Dynamic templates execute in a sandboxed Jinja2 environment: no filesystem access, no imports, no reaching into Python internals — a template can only read the current request and call the small set of documented helper functions. Input length, output length, and recursion depth are all capped, and a template that misbehaves or exceeds a limit returns 422 rather than crashing the request or hanging the server.

Abuse protection

Request bodies over 2 MB are rejected with 413 before your route logic ever runs. Per-IP rate limiting and per-account monthly quotas cap how much traffic a mock (or the management API) accepts in the first place — see Usage, Quotas & Plans for the exact numbers. Random identifiers throughout MockBase — mock ids, tokens, invite codes — are generated with a cryptographically secure source, not a predictable one.

Tracing a request

Every response carries an X-Request-ID header — an id generated for that request, or echoed back if your own client already sent one. It's not a security control by itself, but if you're reporting a problem or correlating a call across systems, that id is the fastest way to point at the exact request you mean.