---

title: Security Model description: How GuardProxy protects your API keys — method-override stripping, TLS integrity, no key storage, no body logging, rate-limit passthrough, and SSRF protection. group: Security order: 1

Security Model

GuardProxy's job is to make your API key safer to use, not to introduce new risk. This page documents exactly how keys and request data are handled.

API key handling

Your API key never touches storage. It arrives in the Authorization header, passes through GuardProxy's infrastructure in memory, and is forwarded to your upstream API. When the request completes, the key is gone.

GuardProxy logs the request path and HTTP method (for the block-log dashboard). It never logs:

• The Authorization header or any API-key-like header.
• The request body.
• Query string parameters.
• Response bodies.

Headers that look like credentials are redacted before any logging.

Method-override header stripping

These HTTP method-override headers are stripped before forwarding:

• X-HTTP-Method-Override
• X-Method-Override
• X-HTTP-Method
• X-Method
• X-Original-Method
• X-Requested-Method

Web frameworks (Express, Rails, Django, and others) honor these to treat a request as a different HTTP method than what was sent. Without stripping, an attacker could send a GET with X-HTTP-Method-Override: DELETE — the GET would pass GuardProxy's method block, but the upstream framework would execute a DELETE. Removing these headers closes that bypass.

TLS integrity

GuardProxy runs on a global edge network. The connection to your upstream API uses HTTPS with certificate validation enforced by the runtime. There's no opportunity for a downgrade attack — the proxy validates the upstream TLS certificate by default.

No data logging

For blocked requests, GuardProxy logs only:

• HTTP method
• Request path (without query string)
• Upstream slug
• Timestamp
• Block reason

Request bodies, API keys, query parameters, and response bodies are never logged. Webhook alerts on block events carry no keys or bodies either.

SSRF protection

Upstream URLs are validated against a blocklist before any forwarding happens. Blocked destinations include:

• Private IP ranges: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 (link-local)
• CGNAT range 100.64.0.0/10
• Cloud metadata endpoints and the .internal TLD
• localhost and multi-label/internal hostnames

The same validation runs when you create or update an upstream in the dashboard, so a malicious URL can't be configured in the first place.

Rate-limit passthrough

If your upstream API returns a 429 rate-limit response, GuardProxy forwards it verbatim, including the Retry-After header. Your client can back off correctly. GuardProxy doesn't add its own rate limiting on top (beyond the platform-level abuse limit).

Response fidelity

All response headers from the upstream are forwarded to the client — Set-Cookie, Content-Type, Cache-Control, and any custom X-* headers. The response body streams through with chunked encoding, content-length, and content-encoding preserved. The only response GuardProxy generates itself is the 403 block response for write methods.