Bug: We don't enforce permissions early on Web publishing #233
Description
Working with the CLI flow of creating comments and documents I found some vulnerabilities worth mentioning
Problem
The write endpoints (/hm/api/document-update, /api/PublishBlobs, /hm/api/debug.store-blob) are completely open — no authentication, no rate limiting, no size constraints. Any client that can reach the server can push arbitrary signed blobs.
The Go daemon's StoreBlobs gRPC handler only validates CID integrity (data matches its hash) but performs no authorization. Capability checks happen later, at blob indexing time:
- Ref blobs are stashed in stashed_blobs if the signer lacks write permission — but they're still stored on disk.
- Change blobs are stored and indexed unconditionally (they're inert without a valid Ref, but still consume storage).
- Comment blobs are stored, indexed, and publicly visible with no capability check at all — only cryptographic signature validity is required.
This means:
- An attacker can fill a server's disk by pushing arbitrarily large garbage blobs.
- Anyone can spam visible comments on any document on any server.
- The server returns 200 Success for all of this, giving the attacker no reason to stop.
The stash-then-reindex pattern is appropriate for P2P replication (where blobs may arrive before their corresponding capabilities due to sync ordering), but it's dangerous when exposed as an unauthenticated public HTTP API.
Solutions
- Add per-IP and/or per-signer rate limiting on write endpoints.
- Add payload size limits to StoreBlobs (max blob size, max blobs per request).
- Reject (not stash) Ref blobs from signers with no capability — the capability check via isValidWriter() can be done synchronously at storage time. Only fall back to stashing for the P2P sync path where ordering isn't guaranteed.