SSRF Protection

Overview

Server-Side Request Forgery (SSRF) attacks trick a server into making requests to internal or sensitive endpoints. Since CueAPI sends webhooks to user-provided URLs, SSRF protection is critical.

What CueAPI blocks

Blocked IP ranges

Blocked hostnames

• localhost
• metadata.google.internal
• metadata.internal

Blocked URL features

• Embedded credentials: https://user:pass@host.com is rejected
• Non-HTTPS schemes (in production): http://, ftp://, file://, javascript: are rejected
• No hostname: URLs without a hostname are rejected

How validation works

1. Parse URL — extract scheme, hostname, credentials
2. Check scheme — HTTPS required in production (HTTP allowed in development)
3. Check credentials — reject user:pass@host
4. Check hostname — reject blocked hostnames
5. DNS resolution — resolve hostname to IP addresses
6. Check IP ranges — reject if any resolved IP is in a blocked range

DNS rebinding protection

CueAPI resolves the hostname at validation time (when the cue is created) and checks all resolved IPs against blocked ranges. This prevents DNS rebinding attacks where a hostname initially resolves to a public IP but later resolves to a private IP.

Error responses

Invalid callback URLs return 400 invalid_callback_url:

{
  "error": {
    "code": "invalid_callback_url",
    "message": "Callback URL resolves to blocked address range",
    "status": 400
  }
}