Security Policy

The API Tester sends your request from Redline's server, not your browser — that's what lets it bypass CORS. To stop that from being abused to reach internal infrastructure, every target URL is checked before the request is made: requests to localhost, loopback, private (RFC 1918), and link-local addresses — including the cloud metadata IP — are rejected outright, both by literal address and by resolving the hostname's DNS first.

Webhook data is stored with row-level security enabled and zero access policies defined. In practice, that means the public/anonymous database credential has no access to inbox data at all — reads and writes only happen through a separate, privileged credential that lives on Redline's server and is never sent to the browser or included in any client-side code. It is also excluded from version control.

There are no accounts, so a webhook inbox is protected the same way a well-known tool like webhook.site protects one: by a long, random, unguessable ID. Anyone with that ID (or the inbox's URL) can view its captured requests — don't share an inbox link anywhere you wouldn't want its contents seen, and delete the inbox when you're done with it.

A captured webhook request is stored exactly as received, including every header. If the service you're testing sends authorization tokens, API keys, or other secrets in its webhook calls, those will be visible in your inbox. Clear or delete the inbox once you're done, and avoid pointing production traffic containing real secrets at a debugging tool for longer than necessary.

In production, Redline is served over HTTPS. Requests the API Tester proxies on your behalf use HTTPS whenever the target URL specifies it.

If you find a security issue — a way around the SSRF guard, a way to access another inbox's data, or anything else — please report it via the Contact page rather than filing a public issue. We'll follow up as quickly as we can.