[DOCS] Security page should warn about DNS rebinding risks for local agent servers

Resolved 💬 2 comments Opened Feb 10, 2026 by coygeek Closed Mar 11, 2026

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:

  1. DNS rebinding attacks: A malicious website tricks the browser into sending requests to localhost:PORT by resolving a hostname to 127.0.0.1. This bypasses same-origin protections and lets any website control the local agent.
  2. Cross-site WebSocket hijacking: WebSocket connections don't enforce same-origin policy by default. Any website can open a WebSocket to ws://localhost:PORT unless the server validates the Origin header.
  3. Local network exposure: Binding to 0.0.0.0 instead of 127.0.0.1 exposes 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:

  1. Always bind to 127.0.0.1, not 0.0.0.0 when running agent servers locally
  2. Validate Origin headers on WebSocket connections to prevent cross-site hijacking
  3. Use token-based authentication (like Jupyter Notebook) for local servers
  4. Don't expose filesystem browsing endpoints without authentication
  5. Don't accept arbitrary binary paths in session creation endpoints
  6. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗