fix(security): add SSRF protection to URL validation

[triepod-ai]

Summary

Adds SSRF (Server-Side Request Forgery) protection to URL validation by blocking requests to private/internal IP addresses.

Changes

• Add isPrivateHostname() helper with comprehensive private IP detection:
  • Localhost variants (localhost, 127.x.x.x)
  • IPv4 private ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x, 0.x)
  • IPv6 private ranges (::1, fe80::, fc00::, fd00::)
  • Cloud metadata endpoints (169.254.169.254, metadata.*)
• Update validateRedirectUrl() to block private IPs by default
• Add allowPrivateIPs option for backward compatibility
• Add isPrivateUrl() utility function for checking without throwing
• Add 18 unit tests for SSRF protection

Security Impact

• Prevents SSRF attacks via OAuth redirect URLs
• Blocks access to cloud metadata endpoints (AWS/GCP)
• Covers IPv4 and IPv6 private ranges

Test plan

• Build passes (npm run build)
• 42 URL validation tests pass (18 new SSRF tests)
• Existing URL validation functionality preserved
• allowPrivateIPs: true allows private IPs for backward compatibility

🤖 Generated with Claude Code

[olaservo]

Thanks for the contribution and for thinking about security!

A few considerations after review:

1. Client-side SSRF protection has fundamental limitations since browser JavaScript cannot perform DNS resolution - an attacker could use a domain that resolves to a private IP, bypassing the check entirely.

2. Inspector runs locally, and OAuth URLs come from server metadata that the user chose to connect to, limiting the attack surface.

3. Inspector V1 is in maintenance mode while V2 is under development, so larger architectural additions are being directed to V2.

If you believe there's a specific exploitable vulnerability, please report it through HackerOne with reproduction steps so the security team can assess it properly.

Thanks again!

---

This comment was drafted with assistance from Claude (AI).

[olaservo]

Closing per the discussion above. If there's a specific exploitable vulnerability, please report via HackerOne.