SSRF: the attack that turns your app into a door to internal cloud
A poorly validated "import from URL" field can read AWS metadata or scan your network. How to block it without killing legitimate features.
Server-Side Request Forgery appears in OWASP Top 10 and Google Security Blog writeups because it is devastatingly simple: your server fetches a URL the attacker controls — or worse, 169.254.169.254 to steal IAM credentials on EC2. SMB apps with "link preview" or scraping integrations are classic targets.
Defense in depth: validate scheme (https only), block privat
Defense in depth: validate scheme (https only), block private IPs and metadata endpoints, resolve DNS and reject internal ranges, use domain allowlists when the use case allows. Never pass raw user URLs to HTTP libraries without sandbox.
On AWS, mandatory IMDSv2 and least-privilege roles limit bla
On AWS, mandatory IMDSv2 and least-privilege roles limit blast radius if SSRF occurs. On Vercel/Netlify, understand what your serverless can reach from the provider network — do not assume total isolation.
For small teams in Puerto Rico: add a security test in CI attempting fetch to http://127.0.0.1 and metadata IP — it must fail. One-line code review checklist on PRs touching outbound HTTP clients.
SSRF is not theoretical; it is how pentesters open paths to internal data stores in hours. A useful feature poorly implemented costs more than delaying release one week for proper validation.
Writes about practical cybersecurity for SMBs in Puerto Rico and the Caribbean — no fluff, just what actually needs to get done.
