A form that accepts a podcast feed URL can look harmless. Your server fetches a public XML document and reads its title. But the same route may be asked to contact a private address or an internal service.
This is a server-side request forgery risk. The danger comes from where the server can connect, not only from what the input text looks like.
Limit the job of the fetcher
Use an isolated feed-fetching component with a clear network policy. Accept only the schemes your product supports. Resolve and validate destinations, including redirects, before following them. A hostname that begins with a familiar word is not proof of a safe public destination.
Block private, loopback, link-local, and other restricted destinations according to your deployment's network design. Consider IPv6 as well as IPv4. DNS changes and redirect chains need attention; validating only the first text URL is not enough.
Set connection, total-time, and response-size limits. A public server can still return an endless or very large response. Parse XML with settings that disable unwanted external resource access.
Keep errors useful and quiet
Tell the listener that the address could not be read without exposing internal connection details. Log a safe reason code for your team. Do not return secret service responses through the public feed preview.
Test a normal public feed, a redirect to a private address, a slow response, and an oversized document. Run those tests in a controlled environment rather than probing unrelated systems.
If a catalog API already provides the lookup you need, compare its documented behavior with operating your own fetcher. Reducing your server's network duties can simplify a difficult security boundary.