[DOCS] Security page should warn about DNS rebinding risks for local agent servers
Documentation Type
Missing documentation (feature not documented)
Documentation Location
https://code.claude.com/docs/en/security
Section/Topic
Security page > "Security best practices" section, or a new section on Agent SDK deployment security.
Current Documentation
The security page covers:
- Permission-based architecture
- Prompt injection protection
- MCP security
- IDE security
- Cloud execution security
- Security best practices (working with sensitive code, team security)
There is no mention of security considerations when using the Agent SDK to build applications that expose agent capabilities over HTTP/WebSocket.
What's Wrong or Missing?
When developers use the Agent SDK (or the CLI) to build web-accessible agent interfaces, they create localhost HTTP servers with powerful capabilities (file system access, command execution, code modification). These servers are vulnerable to:
- DNS rebinding attacks: A malicious website tricks the browser into sending requests to
localhost:PORTby resolving a hostname to 127.0.0.1. This bypasses same-origin protections and lets any website control the local agent. - Cross-site WebSocket hijacking: WebSocket connections don't enforce same-origin policy by default. Any website can open a WebSocket to
ws://localhost:PORTunless the server validates the Origin header. - Local network exposure: Binding to
0.0.0.0instead of127.0.0.1exposes the agent server to the entire local network.
The security page should acknowledge that developers building agent servers face these risks and provide mitigation guidance.
Suggested Improvement
Add a section to the security page (or the Agent SDK secure-deployment.md page) covering:
- Always bind to 127.0.0.1, not 0.0.0.0 when running agent servers locally
- Validate Origin headers on WebSocket connections to prevent cross-site hijacking
- Use token-based authentication (like Jupyter Notebook) for local servers
- Don't expose filesystem browsing endpoints without authentication
- Don't accept arbitrary binary paths in session creation endpoints
- Consider DNS rebinding when building localhost servers with agent capabilities
A brief note in the "Security best practices" section linking to the Agent SDK secure deployment docs would suffice if detailed coverage exists there.
Impact
Medium - Makes feature difficult to understand
Additional Context
The Agent SDK already has a secure-deployment.md page (platform.claude.com/docs/en/agent-sdk/secure-deployment) which may cover some of this. However, the main security page on code.claude.com doesn't reference it, and developers reading the security page wouldn't know to look at the SDK deployment docs.
This is motivated by reviewing The Vibe Companion, which creates a localhost server with no authentication, filesystem browsing, arbitrary binary execution, and WebSocket endpoints -- all accessible to any process on the machine or any website via DNS rebinding.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗