Potential fix for code scanning alert no. 1: Server-side request forgery

[saad2134]

Potential fix for https://github.com/saad2134/donor-sync/security/code-scanning/1

In general, the fix is to prevent arbitrary user input from controlling the URL used in fetch. Instead of accepting a full URL, the code should either (a) select from a fixed set of known‑good base URLs or (b) validate the provided URL strictly and reject anything that is not an HTTPS URL to an expected host (and possibly path prefix). This ensures the server only makes outbound requests to intended verification providers and not to arbitrary internal or external endpoints.

The least invasive, functionality‑preserving change here is to parse user_json_url with the built‑in URL class, validate its components (scheme, hostname, optionally port and pathname), and only proceed with fetch if it passes these checks. Otherwise, return a 400 error. We don’t need new libraries for this; Node/Next.js already provides URL. Concretely, in frontend-web/app/api/verify-email/route.ts, right after checking that user_json_url is present (after line 7–9) and before fetch, we can:

1. Wrap URL parsing in a try/catch to handle invalid URLs.
2. Enforce:
   • parsed.protocol === 'https:' (or 'http:' too if truly needed, but preferably just HTTPS),
   • parsed.hostname belongs to an allow‑list of acceptable verification providers (for example, a single provider domain, or a small set drawn from environment variables).
3. Optionally enforce no custom ports and a required pathname prefix, depending on how strict you want to be.

Then, instead of calling fetch(user_json_url, ...), call fetch(validatedUrl.toString(), ...) (where validatedUrl is the parsed URL that has passed the checks). This preserves existing behavior for legitimate URLs while blocking SSRF vectors.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.