SSRF Check — Can Users Make Your Server Fetch Internal URLs?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A server that fetches user-supplied URLs can be pointed at its own internals — cloud metadata credentials, localhost admin panels, private services.
Why AI tools generate it
Link previews and image proxies are standard AI-scaffold features; the fetch works on the first try, and the URL constraint is the step that never gets written.
How DevMeth detects it
A code scan flags fetch/axios calls in server handlers whose URL derives from the request with no host allowlist in the handler. Relative paths, env-configured URLs, and allowlisted handlers are not flagged.
The server fetches URLs that users control
WHAT WE FOUND
C39 — masked sample
The fix, in three steps
Parse the URL, match its hostname against an exact allowlist before fetching, and block private/link-local ranges for open-ended fetchers.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
Why does this matter if my fetch only returns a preview?
Because the response goes back to the attacker. A fetch of the cloud metadata endpoint returns credentials; a probe of localhost returns whatever the internal service says. The fetch is the attack; the preview is the cover.
My app is a link-preview tool — fetching URLs is the feature.
Then the fix is constraint, not removal: exact-host allowlists for known sources, or DNS-resolved private-range blocking if you must stay open-ended. The scan is advisory — that's the review it asks for.
What's the fix?
`new URL(url).hostname` checked against an exact allowlist before the fetch, plus private-range blocking for open-ended fetchers. Never string-prefix checks.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.