Security: /policy/reload endpoint has no authentication

[Kaspre]

Summary

The POST /policy/reload endpoint accepts unauthenticated requests from any local process. This allows a complete policy replacement without any bearer token, API key, or other credential check.

Impact

For a security-critical authorization sidecar, this is a significant attack surface. A compromised or malicious local process can:

1. POST a permissive policy (e.g., allow-all) to /policy/reload
2. Immediately gain authorization for any action
3. If delegation is enabled, obtain a mandate and execute arbitrary commands

This is especially concerning in shared-host or container environments where multiple processes share localhost.

Suggested Mitigations

• Require a bearer token or shared secret for /policy/reload (consistent with how /v1/authorize can require one in local_idp mode)
• Alternatively, provide a config flag to disable hot-reload entirely (some deployments prefer restart-only policy changes)
• At minimum, document the risk so operators can make an informed decision

Our Workaround

We removed the route entirely from src/http/mod.rs before building. Policy changes require a sidecar restart, which is acceptable for our use case and eliminates the attack surface.

[rcholic]

Thank you so much for the detailed issue report.
We have applied a fix in #29 and made a new release v0.7.0

How to secure the /policy/reload Endpoint in sidecar v0.7.0

Option	CLI Flag	Environment Variable	Effect
Require bearer token	--policy-reload-secret "your-secret"	PREDICATE_POLICY_RELOAD_SECRET	Requires Authorization: Bearer your-secret header
Disable endpoint	--disable-policy-reload	PREDICATE_DISABLE_POLICY_RELOAD=true	Returns 404, policy changes require restart

Example:

./predicate-authorityd --policy-reload-secret "my-secret-token" --policy-file policy.json run

[Kaspre]

Confirmed working in v0.7.1. Using --disable-policy-reload flag — endpoint is correctly disabled, returns 404. This replaces the source patch we had been maintaining since v0.6.7 to manually remove the route. Thank you!

[rcholic]

Confirmed working in v0.7.1. Using --disable-policy-reload flag — endpoint is correctly disabled, returns 404. This replaces the source patch we had been maintaining since v0.6.7 to manually remove the route. Thank you!

That’s great to hear — and especially helpful context that you’d been carrying a source patch since v0.6.7. Knowing where people are forced to fork the sidecar is exactly the kind of signal we want to surface early.

Really appreciate you testing v0.7.1 quickly and confirming the behavior.

You’re clearly exercising the sidecar in real environments beyond the obvious paths, which is valuable feedback for where we take the control plane next (policy distribution, signing, fleet controls, etc.). The control plane handles the Ed25519 cryptographic policy signing and fleet-wide mandate revocation that usually becomes the next bottleneck after local SSRF/routing limits

If you’re open to it, I’d genuinely love to keep the feedback loop open as we build that out — even if it’s just occasional blunt notes on what feels missing or awkward.