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

[arjunkomath]

Potential fix for https://github.com/techulus/cloud/security/code-scanning/4

General approach: keep the hostname fixed (already true: hub.docker.com and registry-1.docker.io) and ensure that any user-controlled URL components (such as tag, digest, or reference) are validated or normalized before interpolation. For a Docker image validator, the main need is to ensure that tag and digest conform to Docker’s allowed formats and that no path traversal or control characters sneak into the URL.

Best concrete fix here: introduce a simple validator for the reference (which is either a tag, a digest, or the constant "latest") and refuse to make the outbound request if it doesn’t match an expected pattern. We can implement this as a small helper (e.g., isValidImageReferencePart) that uses a conservative regular expression to restrict the tag/digest to allowed characters and length. Then, just after computing reference in validateDockerImage, we call this helper; if validation fails, we return { valid: false, error: "Invalid image tag or digest" } before constructing the url and calling fetch. This change only affects the logic in web/actions/projects.ts and does not alter existing external behavior for valid images, it just rejects invalid ones earlier and removes the tainted data from the URL building step.

Concretely:

• Add a small helper function near parseImageReference (within the same file) that checks reference (tag/digest) against a whitelist regex.
• In validateDockerImage, immediately after const reference = digest || tag || "latest";, insert a validation step using this helper.
• If validation fails, log or return a clear error and skip the external HTTP call, so that untrusted, unvalidated data never reaches the fetch URL.

No external packages are strictly required; a simple regex-based check using built-in JS facilities is enough.

---

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