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

[saad2134]

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

In general, to fix SSRF when making server-side HTTP requests using client-supplied URLs, you must prevent the client from controlling the full target URL or host. Common strategies are: (1) don’t accept arbitrary URLs at all; instead accept an ID or enum and map it to a known endpoint, or (2) strictly validate the URL (scheme, host, port, and path) and reject anything outside a narrow allow‑list.

For this specific route, the minimal fix while preserving functionality is to validate user_json_url before calling fetch. We can (a) parse it with the built‑in URL constructor, (b) ensure the protocol is https: (or at least http:/https:), (c) ensure the hostname is in an allow‑list of trusted verification providers, and optionally (d) constrain the port and path. If validation fails, we return 400 rather than issuing the request. This keeps the current pattern of “backend fetches a given verification JSON” but prevents use of arbitrary internal or attacker-controlled hosts. We can implement this entirely within frontend-web/app/api/verify-phone/route.ts using only standard language features, so no new external dependencies are necessary.

Concretely, in POST we will:

• After checking !user_json_url, add a URL parsing/validation block.
• Use new URL(user_json_url) in a try/catch; on failure, return 400 with an error.
• Define an array of allowed hostnames (e.g. const ALLOWED_HOSTS = [...]) and verify parsed.hostname is included.
• Enforce allowed protocols (e.g. https:).
• Use fetch(validatedUrl.toString(), ...) instead of fetch(user_json_url, ...).

Only lines around 7–10 and 19–25 need logic inserted/updated; the rest of the function can remain unchanged.

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