Document security limitations
This commit is contained in:
parent
8ce1e098e6
commit
4c0f0fbf52
1 changed files with 25 additions and 0 deletions
25
CLAUDE.md
25
CLAUDE.md
|
|
@ -79,3 +79,28 @@ each adapter needs:
|
|||
|
||||
see NOTES.txt for cell-grid vs text-crdt mode discussion.
|
||||
see docs/ for full research and architecture breakdown.
|
||||
|
||||
## security
|
||||
|
||||
current state (research prototype):
|
||||
- room name validation (alphanumeric, 1-64 chars)
|
||||
- message type validation via protocol decoder
|
||||
- websocket.send error handling
|
||||
|
||||
known gaps (not production ready):
|
||||
- no authentication (anyone can join any room by name)
|
||||
- no authorization (all peers see all edits)
|
||||
- no rate limiting on messages or room creation
|
||||
- no message size limits
|
||||
- room names guessable via brute force
|
||||
- no encryption (deploy behind wss, not ws)
|
||||
- no audit logging
|
||||
- no persistence (data lost on daemon restart)
|
||||
|
||||
before production:
|
||||
1. auth layer (jwt tokens or unix socket for local-only)
|
||||
2. per-room authorization
|
||||
3. rate limiting (msgs/sec, rooms/minute)
|
||||
4. message size caps
|
||||
5. tls via reverse proxy
|
||||
6. access logging
|
||||
|
|
|
|||
Loading…
Reference in a new issue