How to Prevent SSRF Attacks in AI Applications and SaaS

SSRF attacks in AI applications are behind some of the most damaging breaches of 2026. Server-side request forgery (SSRF) is not a new vulnerability — it has been an OWASP Top 10 staple for years — but AI applications have fundamentally changed its attack surface. Every time your AI feature fetches a URL a user provides, renders a document from an external source, processes a webhook callback, or invokes an AI agent tool that makes outbound HTTP requests, you are creating a potential SSRF entry point. The difference from a traditional SSRF vulnerability is that in AI applications, the attacker does not need to inject a malicious URL directly into a form field. They can instruct the AI through natural language — or embed instructions in a document the AI reads — and the model will generate the malicious request itself.

A 2026 survey of AI agent deployments found SSRF to be a leading cause of cloud credential exposure: attackers exploit agent URL-fetching tools to reach AWS instance metadata endpoints, extract IAM role credentials, and use those credentials to access S3 buckets, database connection strings, and secrets stored in the same AWS account. The attack requires no special access — it needs only an AI feature that fetches URLs and a cloud environment that has not enforced IMDSv2.

This guide covers the full SSRF prevention stack for SaaS and AI applications: why denylists fail, how to build an allowlist architecture, network egress controls, the cloud metadata patterns attackers target first, and how to test for SSRF before an attacker does. For the broader AI agent security picture, see how to secure AI agents in the enterprise.

What Is SSRF and Why Are AI Applications Especially Vulnerable?

In a traditional SSRF attack, an attacker finds a feature that accepts a URL and makes a server-side HTTP request to it — a URL preview endpoint, an image import, an avatar URL field — and supplies an internal address instead of a legitimate external one. The server fetches the internal address and the attacker reaches resources that should only be accessible from within the server's network: internal APIs, database management interfaces, cloud metadata services, or other microservices. The impact ranges from information disclosure to full cloud account compromise, depending on what the internal service returns.

• →AI agents expand the SSRF attack surface to natural language. An attacker who cannot directly supply a URL to an endpoint can write a document, email, or message that instructs the AI to summarize the contents of a URL or check the status of an endpoint. If the agent follows natural language instructions to fetch URLs without validating the target, it creates an SSRF channel that bypasses all URL-based input filtering in the UI.
• →Tool calls are a primary SSRF vector in MCP and function-calling architectures. If an AI agent has a fetch-URL or read-webpage tool, every invocation of that tool is a potential SSRF attempt. Tool parameters need the same validation as form inputs — the trust boundary does not change because the caller is a language model.
• →AI applications typically run in cloud environments with attached IAM roles, making SSRF more dangerous than in a traditional VM. A cloud-hosted AI service often has an IAM role with access to S3 buckets, secrets in Secrets Manager, or database credentials. SSRF to the metadata endpoint exposes the credentials for that role.
• →Redirect chains defeat naive validation. A URL that passes a hostname allowlist check can still redirect to 169.254.169.254 or a private IP range after the initial request succeeds. Validating only the initial URL and following redirects unconditionally leaves the SSRF door open.

AI Agent Tool Calls and the SSRF Attack Surface

Every AI agent feature that makes outbound HTTP requests on behalf of a user creates an SSRF attack surface. AI agent tool calls — specifically tools that fetch URLs, read webpages, process documents from external sources, or call back to user-specified webhooks — are the most common SSRF entry points in AI-integrated SaaS applications. The challenge is that these tools are legitimate features. The goal is not to remove them but to enforce URL validation at the tool execution layer, independent of what the language model generates as a parameter value.

• →Treat every tool parameter as untrusted input, regardless of the caller. A language model generating a URL as a function call argument is not an authorization decision. The URL the model produces may have been injected through the conversation via prompt injection in a document the model processed earlier in the same session. Validate the URL in the tool handler, not at the call site.
• →Define explicit allowed actions per tool in your tool registry. A web browsing tool should only be able to fetch HTTP and HTTPS URLs, never internal IP ranges, loopback addresses, or link-local addresses. Define these constraints in the tool's input schema via JSON Schema pattern or enum constraints and enforce them again in the tool handler's implementation — schema constraints are documentation for the model, not a security control.
• →Log every URL a tool fetches, with the agent session ID, the user ID, and the full resolved URL. This log is both a security monitoring signal for unexpected internal URL fetch attempts and the evidence chain for incident response. An SSRF attempt via tool call will appear as a fetch to an unusual IP range in this log before an attacker successfully exfiltrates credentials.
• →Rate-limit tool invocations per session. Attackers who use prompt injection to drive SSRF often chain multiple requests — first to discover internal IP ranges, then to probe specific addresses, then to fetch metadata. A rate limit on outbound URL fetches per session slows this enumeration and makes the pattern visible in monitoring.

Cloud Metadata Services: The Highest-Stakes SSRF Target

Cloud instance metadata services — reachable at 169.254.169.254 on AWS, Azure, and GCP, and also at metadata.google.internal on Google Cloud — exist to provide compute instances with their own identity credentials and configuration without static credential files on disk. For an attacker, reaching the metadata service from inside an SSRF vulnerability means accessing the IAM role credentials attached to the AI service's compute instance. Those credentials are what everything else in the cloud account depends on.

• →On AWS, enforce IMDSv2 (Instance Metadata Service v2) on every EC2 instance and ECS task. IMDSv2 requires a PUT request to get a session token before metadata requests will succeed, using a hop limit of 1 that prevents requests from reaching the metadata endpoint through an SSRF channel in application code. A simple GET to 169.254.169.254 returns a 401 when IMDSv2 is enforced. Configure this in Terraform with http_tokens = required on the metadata options block — not optional.
• →On Google Cloud, the Metadata Server requires a Metadata-Flavor: Google header on all requests. An SSRF channel that sends a bare GET request will not receive credentials. However, if the vulnerable code copies headers from an incoming user request, an attacker can craft the initial request to include the required header. Configure the metadata server to require Workload Identity where your workload supports it, eliminating static metadata credentials entirely.
• →Block outbound requests to link-local ranges at the network layer, independent of application-level checks. Cloud provider link-local addresses (169.254.0.0/16) and loopback (127.0.0.0/8) should never be reachable from your application code. On Kubernetes, a NetworkPolicy that blocks egress to these ranges provides a defense-in-depth layer that application code cannot bypass.
• →Audit your IAM roles for over-provisioned permissions. SSRF to the metadata service is dangerous in proportion to the IAM permissions the role holds. A compute instance running an AI service does not need ListBuckets on all buckets or GetSecretValue for all secrets. Apply least-privilege IAM policies to AI service roles — the blast radius of SSRF credential theft is bounded by what those credentials can actually reach.

URL Allowlisting: Why Denylisting Fails

The intuitive SSRF defense is a denylist: block requests to 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16. This approach fails because denylists can be bypassed through alternative address representations, DNS rebinding, and redirect chains. An attacker who cannot reach 169.254.169.254 directly may try 0xA9FEA9FE (hex encoding), 2852039166 (decimal representation), or a DNS name that resolves to the blocked address. OWASP's recommended approach is an allowlist: define the set of external hosts your application legitimately needs to fetch from, and reject everything else.

• →Build the allowlist at the hostname level, then resolve and re-validate at the IP level. After the hostname passes the allowlist check, use a synchronous DNS resolution call to get the IP address, then verify that the resolved IP does not fall in any reserved range before making the request. This two-step validation catches DNS rebinding: a hostname that resolved to a legitimate IP when checked may resolve to 169.254.169.254 at request time if the attacker controls the DNS record.
• →Disable redirect following in your HTTP client, or re-validate after each redirect. When a request returns a 3xx response, do not follow the redirect automatically. Extract the Location header URL, run it through your full allowlist and IP validation, and only then make the second request. The original URL may pass validation; the redirect target may point to an internal service.
• →Block non-HTTP and non-HTTPS schemes absolutely. SSRF can exploit file://, gopher://, ftp://, and dict:// URL schemes to reach local files or internal services that do not expose HTTP interfaces. Your URL parser should reject any scheme other than http or https before any other validation runs — a URL with a non-HTTP scheme is not a web URL and should never reach your outbound HTTP client.
• →Do not construct the URL to fetch from user-supplied components. The safest architecture is one where your application fetches only from pre-registered, server-side-stored destinations. When a user wants to register a webhook URL, validate and store it at registration time. When the webhook fires, fetch the stored URL — not a URL supplied in the event payload.

Network Egress Controls: Defense Beyond Application Code

Application-level URL validation is necessary but not sufficient. Code has bugs, URL parsers have edge cases, and experienced attackers invest time finding the bypass that works for your specific implementation. Network egress controls provide a defense-in-depth layer that stops SSRF requests from reaching their target regardless of whether the application-level check failed.

• →On Kubernetes, use NetworkPolicy objects to restrict egress from pods that handle outbound URL fetching. A pod that fetches external URLs for a web browsing AI feature should allow egress to port 80 and 443 on 0.0.0.0/0 for internet traffic, but have explicit deny rules for 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These network policies cannot be overridden by application code — they enforce the egress boundary at the kernel level.
• →Consider running URL-fetching workloads in a separate network segment with no route to your internal services. If the AI feature that fetches external URLs runs in a network that has no peering to your database VPC, your secrets infrastructure, or your internal microservices, then SSRF from that workload cannot reach those targets regardless of what URL is fetched. This network isolation is the strongest SSRF defense available.
• →Use a dedicated egress proxy for all outbound HTTP requests from AI features. Route all outbound traffic through a controlled proxy that enforces its own allowlist, logs every request, and returns a blocked response for requests to internal ranges. The proxy is a single enforcement point that centralizes URL validation policy across all AI features and services, and its logs are the primary signal for detecting SSRF attempts in production.

SSRF in Webhooks, File Imports, and URL Preview Features

SSRF vulnerabilities are not unique to AI features. Three SaaS patterns create SSRF exposure in applications without any AI components: webhook registration, file and document imports, and URL preview generation. These are common SaaS features and each is a classic SSRF entry point if implemented without URL validation.

• →Webhook registration: when a user registers a webhook URL, validate the hostname and resolved IP at registration time and reject URLs that resolve to internal ranges. Store only the validated URL. When the webhook fires, fetch the stored URL — do not accept a URL in the event payload. If your webhook system must support user-specified callback URLs, consider running webhook delivery through a dedicated worker with network egress restricted to internet-routable addresses only.
• →File and document imports: features that fetch documents from a URL the user supplies (PDF imports, CSV imports, image fetches) must apply the same allowlist and IP validation as any other URL-fetching feature. The content type returned does not change whether the SSRF succeeded — the server still fetched the internal address. Validate before fetching, not based on what comes back.
• →URL preview generation: link preview features that fetch Open Graph metadata from user-supplied URLs are textbook SSRF entry points. Apply allowlist validation, resolve the hostname before fetching, disable redirects or re-validate them, and consider running the preview fetcher in an isolated network context. Many SSRF disclosures in well-known SaaS products have traced back to their link preview implementation.

How to Test for SSRF Vulnerabilities Before Launch

SSRF testing requires both automated scanning and manual verification of AI-specific channels. DeployReady covers SSRF-related static analysis checks as part of its security scan — URL-fetching patterns in server-side code, missing IP validation, and HTTP client configurations that follow redirects without re-validation. Use it as the automated baseline; follow it with manual testing that covers the AI-specific SSRF surfaces that static analysis cannot reach.

• →Build an SSRF callback listener for your testing environment. Set up a service at an internal address that logs any HTTP request it receives. When testing a URL preview feature or an AI agent tool that fetches URLs, supply that internal address as the target and check whether the log shows a hit. A hit confirms the SSRF channel is open; no hit means the validation is working. Use an out-of-band interaction testing platform for blind SSRF cases where the response is not returned to the caller.
• →Test every URL-accepting parameter with internal IP ranges, loopback addresses, metadata endpoint addresses, and encoded variants of each. The OWASP SSRF test payload list includes hex-encoded IPs, decimal IPs, URL-encoded representations, and mixed-case scheme variants. Test with and without redirects from an external host to an internal address, and with file://, gopher://, and ftp:// schemes.
• →Audit AI agent conversations for SSRF via prompt injection. After deployment, review a sample of AI agent session logs and check whether any session contains a URL fetch to an unexpected internal or link-local address. Prompt injection attempts that drive SSRF will appear in tool call logs before they succeed — catching the pattern early is the difference between a detected attempt and a credential breach.

Frequently Asked Questions

What is server-side request forgery (SSRF)?

Server-side request forgery (SSRF) is an attack where the attacker tricks the server into making HTTP requests to unintended destinations. The attacker uses the server as a proxy to reach internal resources — cloud metadata services, databases, internal APIs, or other microservices — that are not directly accessible from the internet. Even a blind SSRF that only confirms whether the internal address is reachable can be enough to map an internal network or trigger actions on internal services.

Why are AI applications more vulnerable to SSRF than traditional web apps?

AI applications create SSRF entry points through natural language and AI agent tool calls. An attacker who cannot inject a URL directly into a form field can instruct an AI via chat or embed instructions in a document the AI reads, causing the agent to fetch a URL on their behalf. AI agents with tool call capabilities — web browsing tools, document fetch tools, webhook processors — execute outbound HTTP requests based on model-generated parameters, which can be manipulated through prompt injection earlier in the conversation.

How do I prevent SSRF in my Next.js or Supabase application?

Use an allowlist-based URL validation approach in every Next.js API route or Supabase Edge Function that makes outbound HTTP requests. Parse the URL, verify the scheme is HTTP or HTTPS, resolve the hostname to an IP address, and reject any IP that falls in a reserved range before making the request. Disable redirect following or re-validate each redirect destination. On the infrastructure side, enforce IMDSv2 if running on AWS EC2 or ECS, and use Kubernetes NetworkPolicy to restrict egress from pods handling outbound URL fetches.

What is cloud metadata SSRF and why is it dangerous?

Cloud metadata SSRF is an SSRF attack that targets the cloud provider's instance metadata service at 169.254.169.254. The metadata service returns the IAM role credentials attached to the compute instance. An attacker who successfully reaches this endpoint through an SSRF channel can extract those credentials and use them to access cloud resources — S3 buckets, database passwords, secrets — with the same permissions as the application's service role. On AWS, enforcing IMDSv2 blocks simple SSRF access to the metadata service by requiring a session token obtained through a PUT request with a hop limit of 1.

Does DeployReady detect SSRF vulnerabilities?

DeployReady's static analysis identifies URL-fetching patterns in server-side code that do not apply allowlist or IP validation, HTTP client configurations that follow redirects without re-validation, and exposed metadata endpoint patterns. These checks flag SSRF candidates for manual review. A complete SSRF assessment — including DNS rebinding, blind SSRF, and prompt injection-driven SSRF in AI agent features — requires manual testing. Run DeployReady as the automated baseline, then escalate to a manual audit for the AI-specific surface.

How Belsoft Helps Prevent SSRF and Secure AI Applications

SSRF in AI applications sits at the intersection of two attack surfaces that most security tooling does not cover together: network-level SSRF controls that apply to any server and the prompt injection paths that can drive SSRF through natural language in an AI agent session. Belsoft's security audit service covers both layers: our engineers review every URL-fetching component in your application, test AI agent tool call parameters for SSRF exposure, and verify that your cloud metadata configuration, network egress controls, and HTTP client settings are correctly hardened. For SaaS teams building AI features on Supabase, Next.js, or vibe-coded stacks, the SSRF surface is typically among the highest-risk findings in a manual security audit.

We run DeployReady against every project as a CI gate — it catches the automated baseline of URL validation gaps, exposed secrets, and missing security configurations in seconds. For AI-integrated SaaS products preparing for an enterprise security review, a penetration test, or a SOC 2 audit, book a call with the team to scope a security audit focused on your AI features and cloud infrastructure.

“An AI agent that fetches URLs is a network client. Secure it like one.”