fix: prevent SSRF in /api/detect-favicon by blocking private/internal IPs

[tranquac]

Summary

Prevent Server-Side Request Forgery (SSRF) in the /api/detect-favicon endpoint by validating that user-supplied URLs do not resolve to private or internal IP addresses.

Problem

The HandleDetectFavicon endpoint accepts a user-supplied URL and fetches it server-side using http.Get() without validating that the target is not an internal resource:

resp, err := http.Get(req.URL)  // No SSRF protection

An attacker can use this to:

• Access cloud metadata: POST /api/detect-favicon {"url": "http://169.254.169.254/latest/meta-data/"} — leaks IAM credentials on AWS/GCP/Azure
• Scan internal network: Probe internal services (databases, admin panels) not exposed to the internet
• Read internal services: Access internal HTTP services (Consul, etcd, Kubernetes API)

The findManifestIcon helper also makes follow-up HTTP requests to URLs extracted from the fetched page, enabling chained SSRF where the initial page redirects to an internal target.

Fix

Added IP validation before any outbound HTTP request in the favicon detection flow:

1. validateExternalURL(): Resolves the URL's hostname and checks all resolved IPs against a blocklist
2. isPrivateOrReservedIP(): Blocks RFC 1918 private ranges, loopback, link-local (including cloud metadata 169.254.169.254), and IPv6 equivalents

Blocked ranges:

• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (private)
• 127.0.0.0/8 (loopback)
• 169.254.0.0/16 (link-local / cloud metadata)
• ::1/128, fc00::/7, fe80::/10 (IPv6 equivalents)

Impact

• Type: Server-Side Request Forgery (CWE-918)
• Affected endpoint: POST /api/detect-favicon
• Risk: Cloud credential theft, internal network scanning, internal service access
• OWASP: A10:2021 — Server-Side Request Forgery

[pierre-b]

Hi @tranquac , thanks for the report, I'll implement a fix in the next release.

[pierre-b]

Fixed in https://github.com/Notifuse/notifuse/releases/tag/v29.0