Backlog: Security & deployment hardening
Problem
notify.keywind.cc is a public URL. The handler rejects forged requests with 401 (good), but there is no rate limiting: a bot spraying the endpoint forces an unbounded number of signature verifications and log lines, and — once error alerting exists — could trigger alert storms. Signature verification is cheap but not free, and the log/alert amplification is the real risk.
Proposed solution
- Rate-limit inbound requests at the handler (e.g. a token-bucket keyed by remote/global), returning 429 above the cap. Behind Cloudflare Tunnel the client IP is the tunnel, so a global limiter (plus reliance on Cloudflare's own protections) is the pragmatic default.
- Push protection to Cloudflare where possible — WAF rate-limiting rules / Bot Fight Mode on the
notify.keywind.cc hostname — so junk never reaches the tunnel. (Note: earlier debugging confirmed Cloudflare currently passes automated POSTs through; a rate-limit rule would be additive.)
- Ensure rejects (401/400/429) are not individually alerted (see the error-alerting issue) — count-and-summarize instead.
Notes
- Pairs with the error-alerting work: the alert taxonomy must exclude webhook client-noise.
Backlog: Security & deployment hardening
Problem
notify.keywind.ccis a public URL. The handler rejects forged requests with 401 (good), but there is no rate limiting: a bot spraying the endpoint forces an unbounded number of signature verifications and log lines, and — once error alerting exists — could trigger alert storms. Signature verification is cheap but not free, and the log/alert amplification is the real risk.Proposed solution
notify.keywind.cchostname — so junk never reaches the tunnel. (Note: earlier debugging confirmed Cloudflare currently passes automated POSTs through; a rate-limit rule would be additive.)Notes