Security

This page covers what Redrive protects on its own and what it leaves to your broker account. Every broker operation runs as the connection's account, and which permission each one needs is listed in Getting started.

The password gate

Setting REDRIVE_PASSWORD turns on cookie-based auth in front of the whole app, with login attempts rate limited to five per minute from one address. Leave it unset and there's no login at all: Redrive assumes it's talking only to you, on localhost.

The unprotected banner

Bind beyond loopback without a password, and Redrive logs a warning and shows a banner in the UI for the rest of the session. That's a reasonable state for a trusted internal lab. Anywhere else it's a real exposure: set the password.

Broker credentials at rest

Broker credentials are encrypted with ASP.NET Core Data Protection. On Windows, the encryption keys are DPAPI-protected, tied to the machine and user account. On Linux and macOS, the keys sit on disk beside the database. That's enough to stop a casual read, and a copied database file is useless on its own. It isn't enough to stop someone who already has full access to your data directory.

Message payloads

Message payloads move over AMQP as the connection's account, and Redrive adds no transport protection of its own beyond what that connection already gives you. Which operations travel over AMQP and which go through the management API is mapped in Queues & messages.

DNS rebinding

An unprotected instance bound to localhost is still reachable from a malicious website through DNS rebinding. A page open in your browser can trick the browser into sending requests to localhost:5100 as if they were going to the site's own server. If that's in your threat model, set REDRIVE_PASSWORD even for a local-only install. A Host-header allowlist to close this by default is on the roadmap.