OWASP API7:2023 Server Side Request Forgery, commonly called SSRF, occurs when an API causes the server to fetch a destination that should not be reachable or trusted. The risk appears in features that import files, call webhooks, generate previews, fetch images, process feeds, validate integrations, or connect to remote systems.
What Is OWASP API7:2023 Server Side Request Forgery?
Server Side Request Forgery happens when the server makes an outbound request based on a destination influenced by the client and does not properly restrict where that request can go. OWASP describes SSRF in APIs as a flaw that occurs when an API fetches a remote resource without validating the user-supplied URL.
APIs are especially exposed to this class of risk because modern applications often connect to external systems. Webhooks, integrations, URL previews, import tools, cloud automation, feed readers, and file processors all need outbound access. If that access is not controlled, a useful integration feature can become a path to unintended destinations.
Why SSRF Is Dangerous for APIs
SSRF is dangerous because the request comes from the server, not directly from the caller. That server may have network access, identity context, routing privileges, or integration permissions that the external caller does not have. A weak outbound request design can therefore cross trust boundaries.
It crosses trust boundaries
The API server may be able to reach internal systems, cloud services, management endpoints, or partner networks that are not meant to be reachable through user-controlled inputs.
It hides inside useful features
Webhook delivery, URL preview, file import, connector validation, feed processing, and image fetching are legitimate features that can introduce outbound request risk.
It can expose sensitive data
When outbound requests reach unintended destinations, responses may include internal details, tokens, metadata, service behavior, or sensitive operational information.
It is often missed by perimeter controls
Firewalls and gateways may focus on inbound API traffic while SSRF depends on what the API server is allowed to request outbound.
SSRF should be evaluated alongside API security architecture design, API sensitive data exposure, and why API security fails.
Common OWASP API7 SSRF Patterns to Review
Defensive SSRF review should focus on any feature where an API fetches, validates, calls, imports, previews, scans, or processes a remote destination. The safest designs avoid arbitrary destinations and use controlled connectors or allowlisted targets instead.
| Pattern | What to review | Risk if weak | Priority |
|---|---|---|---|
| Webhook and callback URLs | Destination ownership, protocol, allowlist, redirect behavior, retry behavior, and logging | Unexpected outbound requests | Required |
| URL preview and link unfurling | Remote fetcher isolation, destination validation, response size, timeout, and content handling | Internal destination access or data exposure | Required |
| Import, feed, and connector features | Allowed hosts, integration types, authentication, redirect handling, and egress path | Uncontrolled remote resource fetching | Required |
| Image, file, and document processing | Source validation, file size, response handling, scanning workflow, and isolation boundary | Unsafe fetch and processing behavior | Recommended |
| Cloud and internal automation | Network reachability, cloud metadata protection, service identity, and outbound proxy policy | Access to internal control-plane data | Recommended |
| Arbitrary URL fetch | API accepts any destination and the server fetches it directly | High SSRF exposure | Avoid |
Safe SSRF Review Questions
Defensive OWASP API7 review questions: - Which API features cause the server to fetch, call, preview, import, or validate remote destinations? - Can arbitrary destinations be removed in favor of approved connectors or allowlisted targets? - Are protocols, redirects, DNS behavior, destination ownership, response size, and timeouts controlled? - Are outbound requests routed through an egress policy or controlled fetcher service? - Are internal networks, management endpoints, and cloud metadata paths unreachable from the fetcher? - Are destination validation decisions logged with enough context for SIEM investigation? - Can runtime monitoring detect unexpected outbound destinations and abnormal fetch behavior?
Review patterns should connect with API threat modeling guide, API security CI/CD pipeline, and how to evaluate API security.
How to Prevent Server Side Request Forgery in APIs
SSRF prevention is strongest when the architecture limits outbound request freedom. Validation is important, but it should be paired with allowlists, controlled fetcher services, egress policy, restricted protocols, timeout limits, response handling, and runtime monitoring.
| Prevention control | How it helps | Implementation note |
|---|---|---|
| Avoid arbitrary destinations | Removes the most dangerous design pattern | Use approved connectors or allowlisted destinations |
| Strict destination allowlists | Limits where the server can send outbound requests | Define by feature, tenant, partner, and environment |
| Controlled outbound proxy or fetcher | Centralizes validation, logging, timeout, protocol, redirect, and response policies | Keep fetcher network access minimal |
| Egress restrictions | Prevents application servers from reaching sensitive internal destinations | Use network policy and cloud controls |
| Response and timeout limits | Reduces resource and data exposure from remote fetches | Limit size, redirects, duration, and content handling |
| Blocklist-only validation | Relies on incomplete negative matching | Avoid as the main control |
Example Defensive SSRF Requirement
OWASP API7 prevention requirement: For every API feature that makes a server-side outbound request: - Prefer approved connectors over arbitrary URLs - Validate destination through a strict allowlist - Restrict protocols, redirects, response size, and timeout behavior - Route requests through a controlled outbound proxy or isolated fetcher - Deny access to internal networks, management endpoints, and cloud metadata paths - Log destination category, validation result, policy result, and feature owner - Monitor runtime outbound request behavior and route suspicious events to SIEM
Prevention work should align with API security implementation playbook, API security deployment services, and OWASP API4:2023 Unrestricted Resource Consumption.
Runtime Detection, SIEM, and SSRF Operations
Runtime monitoring helps validate that SSRF controls work in production. It can detect unusual outbound destinations, unexpected redirect behavior, denied destination attempts, unusual connector activity, abnormal response sizes, and server-side fetch behavior outside the approved baseline.
Destination analytics
Monitor destination category, feature, tenant, caller, connector, protocol category, validation result, egress policy result, and blocked attempts.
Outbound behavior baseline
Detect unusual remote fetch volume, unfamiliar destination categories, repeated failures, unexpected redirects, and response-size anomalies.
API discovery and drift
Find new endpoints and features that introduce URL fetching, webhooks, imports, previews, connectors, or callback destinations.
SIEM-ready evidence
Send structured findings with endpoint, caller, feature, destination category, validation result, policy result, risk score, owner, and action.
| Runtime signal | What it may indicate | Operational response |
|---|---|---|
| Unexpected destination category | Possible unsafe remote fetch path or validation gap | Review allowlist and feature owner |
| Denied internal destination attempt | Possible probing, integration error, or misconfiguration | Escalate with caller and feature context |
| Unexpected redirect behavior | Destination validation may not match final fetch behavior | Review redirect policy and fetcher controls |
| New endpoint accepts callback destination | SSRF review may be missing | Add threat model and release gate review |
| Large or unusual remote response | Possible unsafe response handling or resource risk | Review response size and content handling |
| Alert without destination context | SOC cannot validate SSRF risk quickly | Improve event fields |
Example SSRF SIEM Event
{
"alert_category": "api_server_side_request_forgery_risk",
"owasp_category": "API7:2023 Server Side Request Forgery",
"endpoint": "POST /api/integrations/webhook/test",
"method": "POST",
"caller": "tenant_admin_user",
"feature": "webhook_destination_validation",
"destination_category": "blocked_internal_destination",
"validation_result": "denied",
"egress_policy_result": "blocked",
"runtime_signal": "unexpected_outbound_destination_attempt",
"risk_score": 89,
"owner": "integrations-api-team",
"recommended_action": "review webhook destination controls, egress policy, and SSRF runbook"
}Runtime operations should connect with API behavior analytics, API risk scoring, and centralized SIEM log forwarding formats.
SSRF Remediation Workflow
An SSRF finding should trigger review of the affected feature and the outbound request architecture around it. The remediation should remove arbitrary destination access where possible and reduce the blast radius of any server-side fetch behavior that must remain.
Validate the affected feature
Confirm endpoint, feature, caller, destination category, validation result, egress policy, response handling, and business need for outbound access.
Restrict destinations
Move from arbitrary destinations to approved connectors, allowlists, ownership validation, and feature-specific destination policy.
Harden the fetch path
Use isolated fetchers, strict egress controls, redirect controls, protocol restrictions, response size limits, timeouts, and safe logging.
Validate and monitor
Add regression tests, release gates, runtime detections, SIEM fields, runbooks, owner mapping, and post-release monitoring.
Example Remediation Tracker Entry
OWASP API7 remediation tracker: - Finding: webhook test feature attempted blocked internal destination - Affected API: POST /api/integrations/webhook/test - Feature: webhook destination validation - Owner: integrations-api-team - Fix: strict destination allowlist, redirect policy, outbound proxy enforcement, and response-size cap - Related review: webhook delivery, connector validation, URL preview, import, and feed ingestion APIs - Tests: allowed destination, denied internal destination, redirect denied, timeout behavior, SIEM event quality - Runtime validation: monitor destination baseline and blocked attempts after release - Status: remediation and validation required
Remediation should align with API security operational handover, API security managed detection service, and API security executive reporting.
OWASP API7:2023 SSRF Prevention Checklist
Use this checklist to evaluate whether APIs are protected against Server Side Request Forgery.
| Checklist item | Question to answer | Status |
|---|---|---|
| Outbound feature inventory | Are webhook, callback, preview, import, connector, feed, file, image, document, and remote fetch features documented? | Required |
| Destination control | Are arbitrary destinations avoided or restricted through strict allowlists and approved connectors? | Required |
| Protocol and redirect policy | Are protocols, redirects, final destination behavior, response size, and timeout controls defined? | Required |
| Egress restrictions | Can the fetcher reach only destinations required by the business feature? | Required |
| Cloud and internal protection | Are internal networks, management endpoints, and cloud metadata paths unreachable from server-side fetch features? | Required |
| Runtime monitoring | Can teams detect unusual outbound destinations, denied attempts, redirect anomalies, and response-size issues? | Recommended |
| SIEM workflow | Do SSRF events include endpoint, caller, feature, destination category, validation result, policy result, risk score, owner, and action? | Recommended |
| Release gates | Do CI/CD and AppSec reviews flag new URL-fetch, webhook, connector, import, preview, and callback features? | Recommended |
| Blocklist-only model | Is the team relying only on blocked destination strings without architecture-level egress control? | Avoid |
Common API Security Risks Connected to SSRF
OWASP API7:2023 Server Side Request Forgery connects to the broader API security operating model. Runtime API visibility, request and response inspection, sensitive data exposure, API behavior analytics, API abuse detection, BOLA and IDOR signals, broken object property authorization, business logic abuse, API data leakage, token and secrets leakage, replay attacks, enumeration attacks, SIEM-ready events, incident response, API forensics, API threat hunting, alert fatigue reduction, vendor evaluation, safe enforcement, customer onboarding, proof of value, managed service delivery, executive reporting, renewal planning, and expansion opportunities all matter when building a complete defense.
The practical approach is to identify server-side fetch features during design, restrict outbound access before release, monitor destination behavior in production, and route findings into SIEM, AppSec, cloud, platform, API owner, and executive reporting workflows.
Conclusion
OWASP API7:2023 Server Side Request Forgery is a serious API risk because APIs often fetch remote resources as part of valuable integrations and automation workflows. Without destination control, a useful feature can allow the server to make requests the business never intended.
Strong SSRF defense combines outbound feature inventory, strict allowlists, controlled connectors, isolated fetchers, egress restrictions, cloud and internal destination protection, runtime destination analytics, SIEM-ready evidence, runbooks, owner mapping, remediation tracking, and executive reporting.
FAQ
What is OWASP API7:2023 Server Side Request Forgery?
OWASP API7:2023 Server Side Request Forgery, or SSRF, is an API risk where the server can be caused to fetch a remote or internal resource in a way the application did not intend because user-controlled destinations are not safely validated or restricted.
Why is SSRF a serious API security risk?
SSRF is serious because APIs often fetch URLs, call integrations, process webhooks, import resources, generate previews, or connect to third-party services. If destination controls are weak, the server may make requests to unexpected internal or sensitive locations.
How does SSRF happen in APIs?
SSRF can happen when an API accepts a URL, callback, webhook, import source, image source, file reference, feed, connector, or remote destination and uses the server to fetch it without strong validation, allowlisting, egress controls, and monitoring.
What API features are commonly associated with SSRF risk?
Common SSRF-sensitive features include webhooks, URL previews, file import, image processing, PDF generation, feed ingestion, integrations, connectors, callback URLs, cloud automation, monitoring checks, and any feature where the server fetches user-supplied destinations.
Are URL blocklists enough to prevent SSRF?
No. URL blocklists are usually not enough because destination handling can be complex. Safer designs use strict allowlists, controlled connectors, canonical validation, restricted protocols, DNS and redirect handling, network egress controls, and runtime monitoring.
How can teams prevent API SSRF?
Teams can prevent API SSRF by avoiding arbitrary outbound requests, using destination allowlists, validating URLs safely, restricting protocols, controlling redirects, isolating fetchers, limiting egress, protecting cloud metadata paths, enforcing timeouts, and monitoring outbound request behavior.
How should webhooks be designed to reduce SSRF risk?
Webhook designs should validate destination ownership, limit allowed protocols and destinations, control redirects, use outbound proxy policy, log delivery attempts, apply timeouts, avoid sensitive network reachability, and monitor unusual callback destinations.
How can runtime monitoring detect SSRF risk?
Runtime monitoring can detect SSRF risk by identifying unusual outbound destinations, unexpected internal network requests, suspicious webhook targets, abnormal URL-fetch behavior, repeated failed fetches, redirect anomalies, and API flows that connect user input to server-side outbound requests.
What SIEM context matters for SSRF detection?
Useful SIEM context includes endpoint, method, caller, feature, destination category, validation result, protocol category, redirect behavior, response status, outbound policy result, risk score, API owner, and recommended action.
How should SSRF findings be remediated?
SSRF findings should be remediated by validating the affected feature, removing arbitrary destinations where possible, adding allowlists and egress controls, hardening redirect and protocol handling, isolating the fetch process, adding tests, updating runbooks, and validating runtime behavior.
How should SSRF be tested safely?
SSRF should be tested safely only in authorized environments using controlled internal test services and documented scenarios. Testing should confirm allowed and denied destinations, redirect handling, protocol restrictions, egress policy, timeout behavior, and SIEM event quality.
What mistakes should teams avoid with SSRF prevention?
Avoid accepting arbitrary URLs, relying only on blocklists, trusting client-side validation, ignoring redirects and DNS behavior, allowing broad outbound network access, exposing cloud metadata paths, skipping runtime monitoring, and routing alerts without destination context.
Reduce SSRF risk with runtime API visibility and outbound request control
Ammune helps security teams and partners identify OWASP API7 SSRF risk with runtime API discovery, outbound request monitoring, sensitive data exposure detection, API abuse analytics, SIEM-ready events, risk scoring, API forensics, operational handover, managed detection, and executive reporting.