OWASP API7:2023 Server-Side Request Forgery, or SSRF, appears when an API makes an outbound request to a destination influenced by a caller without enforcing the business-approved destination, protocol, port, redirect, network, and response policy. The risk often hides inside useful features such as webhooks, URL previews, remote imports, integrations, media processing, and connector tests.
What Is OWASP API7:2023 Server-Side Request Forgery?
In an SSRF condition, the server acts as the requester. That matters because the server may have network access, service identity, credentials, routing privileges, or trusted relationships that the external caller does not have.
A secure outbound feature should answer:
- Does this business feature need to contact a caller-selected destination?
- Which schemes, hostnames, ports, paths, and media types are allowed?
- May the destination resolve to public, private, loopback, link-local, reserved, or management addresses?
- Are redirects required, and is every redirect target revalidated?
- Which network destinations can the fetcher actually reach?
- Which identity and credentials does the outbound request carry?
- How much data, time, bandwidth, and processing may the request consume?
- What information may be returned to the caller or stored in logs?
Basic SSRF vs. Blind SSRF
| Type | Caller feedback | Typical evidence | Operational challenge |
|---|---|---|---|
| Basic SSRF | The API returns remote content, status, timing, or a detailed result | Request and response correlation, returned fields, status, size, destination logs | Preventing sensitive response relay and destination access |
| Blind SSRF | The API initiates the request but does not return the remote response | Controlled callback, DNS, proxy, egress, connection, timeout, and job telemetry | Proving whether the outbound request occurred and what it reached |
Blind SSRF can still create serious impact even when the caller sees only a generic success or timeout. The outbound request may reach a sensitive system, trigger an action, or disclose information through another channel. Detection therefore needs server-side and network evidence rather than client-visible responses alone.
Why SSRF Is Dangerous for APIs
It crosses trust boundaries
The application can reach destinations that the caller cannot contact directly.
It uses server identity
Outbound clients may attach service credentials, client certificates, cookies, or trusted network identity.
It targets control channels
Cloud, container, orchestration, management, and internal services often expose HTTP interfaces inside trusted networks.
It hides inside normal features
Webhook tests, imports, previews, scans, and connectors naturally make outbound requests.
It can relay data
Remote responses, error messages, timing, files, and status information may disclose internal details.
It can create resource pressure
Slow, large, recursive, or repeatedly retried destinations can consume workers, bandwidth, storage, and third-party cost.
SSRF vs. Open Redirects, Unsafe API Consumption, and Resource Abuse
| Risk | Primary question | Example distinction |
|---|---|---|
| SSRF | Can the server be made to request an unintended destination? | The application fetcher connects somewhere outside the approved policy |
| Open redirect | Can a client be redirected to an untrusted destination? | The browser or client follows the redirect, not the application server |
| Unsafe API consumption | Does the application trust a third-party response too much? | The destination may be approved, but its content is not validated safely |
| Unrestricted resource consumption | Can the caller make the server consume excessive resources? | A remote fetch causes large downloads, long timeouts, or repeated processing |
| Sensitive data exposure | Does the API return data the caller should not receive? | An SSRF response or error may reveal sensitive internal information |
One feature can involve several risks. A webhook tester may have SSRF through destination control, API4 exposure through unlimited retries, and sensitive-data exposure if the remote response is returned to the user.
Common OWASP API7 SSRF Patterns
| Feature | What to review | Safer design |
|---|---|---|
| Webhook and callback registration | Destination ownership, test requests, redirects, retries, secrets, and response display | Verified endpoints, restricted destinations, bounded tests, safe response handling |
| URL preview or link unfurling | Destination, redirects, content type, response size, images, and embedded fetches | Isolated fetcher, strict policy, small limits, no internal reachability |
| Remote image or file import | Source URL, file type, expanded size, redirects, processing, and storage | Approved sources or direct upload, isolated processing, bounded content |
| Feed, connector, and integration setup | Custom endpoints, credentials, test calls, tenant scope, and destination changes | Predefined connector types and feature-specific allowlists |
| PDF or document generation | Remote images, styles, templates, references, and renderer network access | Disable network access or use controlled asset retrieval |
| Monitoring and health checks | Who may choose a target, network reachability, protocol, port, and result detail | Approved target inventory and isolated monitoring network |
| Proxy or fetch endpoint | Whether arbitrary destinations are the intended product capability | Strong identity, narrow policy, dedicated infrastructure, and explicit risk acceptance |
| GraphQL or batch integration mutation | Nested destination fields, bulk requests, test actions, and response relay | Apply destination policy to every item and every redirect |
Define an Outbound Request Trust Model
Document outbound behavior as carefully as inbound API access.
Feature and business purpose API endpoint, operation, owner, and callers Who controls the destination Allowed schemes, hostname patterns, ports, and paths Required redirect behavior and maximum hops Expected DNS and address classes Outbound proxy, fetcher, namespace, account, and network zone Service identity, credentials, headers, and client certificates Maximum request time, response size, and retry count Allowed media types and content-processing rules Whether remote content is returned, stored, transformed, or scanned Logging, masking, telemetry, and SIEM requirements Cloud metadata and management destinations that must be unreachable Approved exceptions, owner, expiration, and review trigger
Build the policy by feature. A profile-image importer, enterprise webhook, and partner connector may require different destinations and response handling.
SSRF Prevention Architecture
OWASP recommends isolating the remote-fetching mechanism, using allowlists where possible, restricting schemes and ports, disabling redirects, using maintained parsers, validating caller input, and avoiding raw response relay. The most reliable architecture uses several layers together.
| Layer | Control | Why it matters |
|---|---|---|
| Product design | Avoid arbitrary destinations and use predefined connectors | Removes the broadest SSRF capability |
| Application policy | Allowlist schemes, hosts, ports, paths, and content types | Defines the intended business destinations |
| URL and DNS validation | Parse consistently, normalize, resolve, and classify destinations | Reduces parser, alternate-address, and rebinding gaps |
| Redirect policy | Disable or revalidate every hop | Prevents an approved starting URL from reaching a prohibited final destination |
| Network egress | Default-deny or narrowly allow outbound destinations | Limits impact if application validation fails |
| Fetcher isolation | Separate network zone, workload identity, credentials, and storage | Reduces trust and blast radius |
| Response handling | Limit size, time, media type, redirects, processing, and returned detail | Reduces data relay and resource abuse |
| Runtime evidence | Log policy, destination, DNS, connection, response, and health outcomes | Supports detection and control verification |
Validate URLs and Destinations Safely
Use a maintained URL parser supported by the runtime, and keep validation and connection behavior aligned. Avoid hand-written regular expressions as the only parser.
- Accept only the schemes required by the feature, normally a narrow set such as HTTPS.
- Reject embedded user information, unexpected fragments, unsupported ports, and malformed authority components.
- Normalize hostnames according to one documented policy before matching.
- Prefer exact host allowlists or controlled subdomain rules over broad suffix checks.
- Verify that subdomain matching respects label boundaries.
- Resolve the hostname and classify every returned IPv4 and IPv6 address.
- Reject destinations in prohibited classes, including loopback, link-local, private, reserved, multicast, and management networks unless explicitly required and isolated.
- Use the validated destination for the actual connection and preserve TLS hostname verification.
- Apply the same rules to every redirect and every destination in a batch.
- Record the normalized destination and decision without logging secrets from the URL.
Control Redirects, DNS Changes, and Parser Differences
| Risk | Safer requirement |
|---|---|
| Automatic redirects | Disable by default; when required, cap hops and validate every new destination before connecting |
| DNS rebinding or rapid changes | Validate the address used for connection and avoid a separate unchecked resolution step |
| Multiple DNS answers | Evaluate all returned addresses rather than accepting the first safe-looking result |
| IPv4 and IPv6 differences | Apply the same destination classes and restrictions to both families |
| Parser disagreement | Use the same canonical representation for policy and outbound connection |
| Proxy interpretation | Confirm that application and outbound proxy agree on scheme, host, port, and destination |
| Certificate mismatch | Keep normal TLS hostname and certificate verification enabled |
| Allowlist changes | Version, review, test, and monitor destination-policy updates |
RFC 3986 defines generic URI syntax, but real URL libraries and protocols apply additional rules. Security testing should therefore cover the actual parser, HTTP client, proxy, DNS resolver, and redirect behavior used in production.
Isolate Fetchers and Restrict Outbound Network Access
Place remote-fetch functionality in a workload with the minimum network and identity access required.
- Separate the fetcher from application servers that can reach databases, management services, and internal APIs.
- Use default-deny egress or a narrowly controlled outbound proxy where the platform supports it.
- Allow only required DNS resolvers and destination classes.
- Prevent direct access to internal, link-local, management, and metadata networks.
- Use a dedicated service identity without broad cloud or application permissions.
- Do not attach user cookies, internal authorization headers, or unrelated service credentials.
- Keep temporary storage isolated and apply lifecycle cleanup.
- Monitor denied and permitted outbound connections, DNS, retries, and policy changes.
For Kubernetes, egress isolation depends on a network implementation that enforces NetworkPolicy. Validate the actual cluster behavior rather than assuming that a policy object alone creates isolation.
Protect Cloud Metadata and Management Endpoints
Cloud metadata services and management channels are attractive SSRF targets because workloads can use them for identity, configuration, or credentials. Protect them with several controls:
- Block remote-fetch workloads from reaching metadata and host-management endpoints unless the feature explicitly requires access.
- Use local firewall, network, pod, or process restrictions to narrow which workloads can reach metadata.
- Use token-based, authenticated, or hardened metadata protocols offered by the cloud provider.
- Remove unnecessary instance or workload permissions so metadata access yields minimal capability.
- Separate user-controlled remote fetching from workloads that hold privileged cloud identities.
- Monitor metadata access, changes to metadata policy, and unusual credential use.
For example, AWS supports requiring IMDSv2, Azure documents request safeguards and process-level restrictions for IMDS, and Google Cloud requires metadata-specific request headers and provides hardened metadata options. These controls reduce risk but do not replace destination validation and egress isolation.
Design Safer Webhook and Callback Features
| Webhook stage | Security requirement |
|---|---|
| Registration | Authenticate the caller, restrict destination policy, and associate the endpoint with the tenant and integration |
| Ownership verification | Use a controlled challenge that does not disclose internal secrets or raw fetch results |
| Test delivery | Limit frequency, body, headers, redirects, timeout, and response detail |
| Production delivery | Sign events, use bounded retries and backoff, preserve idempotency, and isolate delivery workers |
| Destination change | Revalidate ownership, policy, DNS, and network reachability |
| Failure handling | Do not reveal internal network or detailed connection diagnostics to untrusted users |
| Operations | Monitor destination category, change history, failures, retries, unusual volume, and policy denials |
Limit Remote Responses and Content Processing
Even an approved public destination can return unsafe or unexpectedly large content.
- Set short connection, read, total-operation, and idle timeouts.
- Limit response bytes, decompressed bytes, files, redirects, and nested fetches.
- Accept only the media types required by the feature and verify content independently of the filename.
- Process remote content in an isolated environment with bounded CPU, memory, storage, and execution time.
- Avoid returning raw headers, bodies, connection errors, or internal diagnostics to the caller.
- Strip or prevent forwarding of internal credentials and sensitive headers.
- Use safe cache keys and avoid sharing one tenant’s fetched content with another.
- Record derived evidence such as type, size, status category, and policy result instead of unnecessary raw content.
Defensive SSRF Testing Method
Testing should be authorized, controlled, and designed to validate policy without probing unrelated internal systems. Use owned test destinations, controlled callback services, isolated labs, and approved non-production environments.
| Step | Assessment activity | Evidence |
|---|---|---|
| 1. Inventory outbound features | Find webhooks, previews, imports, connectors, renderers, scanners, and remote fetchers | Feature, endpoint, owner, and network map |
| 2. Define allowed behavior | Document schemes, hosts, ports, redirects, address classes, credentials, content, and limits | Approved outbound trust model |
| 3. Test expected destinations | Confirm legitimate integrations work through the intended proxy and policy | Positive test and operational evidence |
| 4. Test policy boundaries | Use controlled destinations representing prohibited categories and alternate parsing cases | Validation, DNS, egress, and response results |
| 5. Test redirects and DNS | Confirm every hop and actual connection destination are revalidated | Redirect chain and resolved-address evidence |
| 6. Test response limits | Validate timeout, size, media-type, decompression, and processing boundaries | Bounded resource and error behavior |
| 7. Test blind detection | Use an approved callback destination and verify DNS, proxy, egress, and SIEM evidence | End-to-end detection result |
| 8. Create regression gates | Turn confirmed behavior into automated tests and release requirements | Repeatable acceptance criteria |
Use API security testing vs. runtime monitoring to combine pre-release testing with production evidence.
Runtime Signals for SSRF
| Runtime signal | Possible meaning | Validation context |
|---|---|---|
| First-seen destination category | New integration, shadow feature, configuration drift, or probing | Feature, tenant, release, allowlist, owner, and business purpose |
| Prohibited address decision | Malformed integration, test activity, or attempted internal access | Caller, endpoint, parsed host, resolved addresses, and policy result |
| Unexpected redirect | An approved initial URL points to an unapproved destination | Redirect chain, final destination, certificate, and response |
| DNS and connection mismatch | Resolution changed or the connection did not use the validated address | Resolver, timestamp, returned addresses, proxy, and connection evidence |
| Remote response anomaly | Unexpected type, size, status, or internal-looking content | Destination policy, content classification, caller, and handling path |
| Repeated timeout or connection probing | Misconfiguration, availability issue, or blind destination testing | Caller, tenant, destination category, timing, and volume |
| Metadata or management access | Workload, library, or attacker-controlled fetch reached a protected control channel | Process, identity, network policy, destination, and credential use |
| Fetcher policy disappears | Route, proxy, egress, or deployment drift may have bypassed controls | Version, environment, policy, traffic path, and telemetry health |
| Telemetry gap | Blind SSRF cannot be assessed reliably for affected features or periods | DNS, proxy, egress, application, and SIEM source health |
Reduce False Positives
Use feature context
A destination can be valid for one connector and prohibited for another.
Correlate changes
New partners, releases, migrations, and webhook updates can explain first-seen destinations.
Separate denied from successful
A blocked destination attempt is not the same as a completed request or returned response.
Normalize destinations
Use canonical scheme, host, port, and category while preserving relevant redirect and DNS evidence.
Segment by tenant and identity
Approved destinations and volumes can differ by partner, customer, service, and environment.
Track telemetry health
Missing DNS or egress evidence should lower confidence rather than create a false claim of safety.
SIEM-Ready SSRF Event Model
Event category, confidence, and severity Application, environment, API endpoint, operation, version, and owner User, workload, token, client, tenant, partner, and source context Remote-fetch feature and business purpose Normalized scheme, hostname category, port, path category, and destination class DNS answers, resolver, validation time, and connection destination Redirect count, destination changes, and final policy decision Outbound proxy, egress policy, network zone, and fetcher identity Request headers or credentials category without secret values Response status category, media type, size, timing, and handling result Blocked, permitted, failed, timed out, or returned-to-caller outcome Related attempts, destination changes, jobs, and campaign context Telemetry-health and evidence limitations Recommended validation, containment, configuration, or engineering action Case and correlation identifiers
Use centralized SIEM log-forwarding formats and link events to application, DNS, proxy, network, and cloud evidence.
SSRF Remediation and Verification Workflow
| Phase | Required work | Closure evidence |
|---|---|---|
| 1. Validate | Confirm the feature, caller influence, parser, destination, DNS, redirects, network path, response, and business requirement | Controlled reproduction or production evidence |
| 2. Contain | Disable the feature, restrict destinations, block egress, remove credentials, or isolate the fetcher when urgent | Effective temporary control |
| 3. Reduce destination freedom | Replace arbitrary URLs with approved connectors, exact allowlists, or verified customer endpoints | Reviewed product and policy change |
| 4. Harden validation and fetch | Correct parsing, DNS, redirect, port, response, timeout, and content rules | Implementation and policy evidence |
| 5. Restrict the network | Apply fetcher isolation, egress policy, metadata protection, and least-privilege identity | Network and cloud validation |
| 6. Review related features | Check other webhooks, imports, previews, renderers, connectors, versions, and environments | Recurring-root-cause assessment |
| 7. Test and observe | Validate allowed integrations, prohibited destinations, redirects, blind evidence, and production telemetry | Passing tests and runtime evidence |
| 8. Close or accept | Close only when acceptance criteria are met or residual risk is approved with an expiration | Verified closure or time-bound exception |
Use API forensics for incident scoping and the API security incident-response playbook for containment and coordination.
OWASP API7 Program Metrics
| Metric | Definition | Interpretation caution |
|---|---|---|
| Outbound-feature inventory coverage | In-scope remote-fetch features with owner and trust model / all identified remote-fetch features | Discovery quality determines the denominator |
| Destination-policy coverage | Remote-fetch features with explicit schemes, hosts, ports, redirects, addresses, and limits / all in-scope features | A documented policy does not prove enforcement |
| Egress-isolation coverage | High-risk fetchers with tested network restrictions / all high-risk fetchers | Policy objects must be validated in the deployed network |
| Runtime destination visibility | Critical fetch features with destination, DNS, redirect, egress, and health evidence / all critical fetch features | State unobservable features separately |
| Prohibited-destination decision rate | Requests denied by destination or egress policy / monitored fetch attempts | Separate user error, testing, misconfiguration, and malicious behavior |
| Successful unexpected fetch count | Validated connections outside approved destination policy | Prioritize by identity, response, and reachable capability |
| Mean time to validate | Time from SSRF signal to reliable disposition and owner assignment | Blind SSRF can require multiple evidence sources |
| Mean time to contain | Time from confirmed material SSRF risk to effective destination or network control | Track temporary containment separately from permanent remediation |
| Verified remediation rate | Closed material findings with passing destination, network, and runtime evidence / all closed material findings | Code changes alone are not closure proof |
| Recurring root-cause rate | Previously addressed arbitrary-fetch, redirect, DNS, egress, or credential failures that return | Normalize by root cause rather than event title |
90-Day SSRF Improvement Roadmap
| Period | Primary objective | Key outputs |
|---|---|---|
| Days 1–30 | Inventory and define | Remote-fetch features, owners, destination needs, data and credentials, network paths, current controls, telemetry, and pilot scope |
| Days 31–60 | Restrict and test | Destination allowlists, parser and redirect rules, isolated fetchers, egress policy, cloud metadata controls, controlled tests, and SIEM events |
| Days 61–90 | Verify and operationalize | Production validation, dashboards, runbooks, metrics, CI/CD gates, exception review, and prioritized expansion |
OWASP API7:2023 SSRF Prevention Checklist
| Checklist item | Validation question | Status |
|---|---|---|
| Outbound features inventoried | Are webhooks, previews, imports, connectors, renderers, scanners, proxies, and remote fetchers known? | Required |
| Business need challenged | Can arbitrary destinations be replaced with direct upload, approved connectors, or verified endpoints? | Required |
| Destination allowlist | Are allowed schemes, hosts, ports, paths, and destination categories defined by feature? | Required |
| Safe parsing | Does a maintained parser produce the same canonical destination used by the outbound client? | Required |
| DNS and address validation | Are all resolved IPv4 and IPv6 addresses evaluated and tied to the actual connection? | Required |
| Redirect policy | Are redirects disabled or limited and revalidated at every hop? | Required |
| Egress restrictions | Can the fetcher reach only required public or partner destinations? | Required |
| Fetcher isolation | Does the remote-fetch workload have minimal network, identity, credential, and storage access? | Required |
| Cloud metadata protection | Are metadata and management endpoints unreachable or strongly restricted with cloud-specific hardening? | Required |
| Credential handling | Are internal cookies, tokens, headers, and client certificates excluded unless explicitly required? | Required |
| Response limits | Are time, size, media type, decompression, storage, processing, and returned detail bounded? | Required |
| Defensive testing | Are allowed, prohibited, redirected, DNS-changing, blind, and resource-boundary cases tested safely? | Required |
| Runtime monitoring | Can teams see destination, DNS, redirects, egress, response, outcome, and telemetry health? | Recommended |
| Verified remediation | Are fixes validated in the deployed network and observed before closure? | Required |
| Blocklist-only protection | Is the design relying mainly on a list of forbidden strings or addresses? | Avoid |
For placement and trust boundaries, use API security architecture design. For delivery controls, use API security CI/CD pipeline and the API security implementation playbook.
Common SSRF Prevention Mistakes
Checking only the scheme
HTTPS does not prove that the hostname, address, port, redirect, or network destination is approved.
Using a blocklist as the main defense
Address forms, IPv6, DNS, redirects, parsers, and new internal ranges make negative lists fragile.
Validating only the first URL
An allowed initial destination can redirect to a prohibited target.
Ignoring the actual connection
DNS results can change between validation and use, or a proxy may interpret the URL differently.
Letting the fetcher use application credentials
Outbound requests should not inherit unrelated identity, cookies, tokens, or privileged cloud roles.
Allowing broad egress
Application validation errors become much more serious when the workload can reach internal control channels.
Returning raw remote responses
Response relay can expose internal content and make SSRF easier to validate.
Closing after a parser fix
Redirect, DNS, network, cloud, credential, response, and runtime controls also require verification.
Authoritative Guidance
- OWASP API7:2023 Server-Side Request Forgery defines the official API risk and recommends isolation, allowlists, redirect restrictions, maintained parsers, input validation, and safe response handling.
- OWASP Server-Side Request Forgery Prevention Cheat Sheet provides application- and network-layer defensive guidance.
- OWASP Server-Side Request Forgery explains the broader attack class and trust-boundary impact.
- NIST SP 800-228 Update 1 provides API risks and recommended controls across pre-runtime and runtime lifecycle stages.
- RFC 3986 defines generic URI syntax used by parsers and protocols.
- Kubernetes Network Policies describes workload ingress and egress isolation when supported by the cluster network implementation.
- AWS EC2 Instance Metadata Service documents IMDSv2 and metadata-service configuration.
- Azure Instance Metadata Service documents request safeguards and options for restricting process access.
- Google Cloud VM Metadata documents metadata request requirements and hardened access options.
Conclusion
OWASP API7:2023 SSRF is not solved by checking whether a user-supplied value looks like a URL. A secure design controls why the server makes the request, which destination is permitted, how the hostname resolves, what redirects can occur, which networks the fetcher can reach, which identity it carries, how remote content is handled, and what evidence reaches operations.
The strongest defense combines narrow product design, exact destination policy, maintained parsing, redirect and DNS validation, isolated fetchers, default-deny egress, cloud metadata protection, bounded responses, controlled testing, runtime monitoring, SIEM workflows, and verified remediation. That layered model protects useful integrations without giving callers unintended access through the server.
Frequently Asked Questions
What is OWASP API7:2023 Server-Side Request Forgery?
OWASP API7:2023 SSRF occurs when an API makes a server-side request to a destination influenced by a caller without safely restricting the destination, protocol, redirects, network reachability, and response handling.
What is the difference between basic SSRF and blind SSRF?
With basic SSRF, the API returns information from the fetched destination or otherwise gives the caller direct feedback. With blind SSRF, the outbound request occurs but the caller does not receive the remote response, so detection relies more heavily on controlled testing, destination logs, DNS, egress, and runtime telemetry.
Which API features commonly introduce SSRF risk?
Common features include webhooks, callback validation, URL previews, remote image or document import, feed readers, connector setup, custom integrations, PDF generation, link scanning, proxy functions, and any operation that fetches a caller-influenced URI.
Is validating that a URL starts with HTTPS enough?
No. Scheme validation alone does not restrict the hostname, resolved address, port, redirect destination, parser interpretation, or network path. A secure design validates the complete destination and combines application checks with egress restrictions.
Why are blocklists weak SSRF controls?
Blocklists are difficult to maintain across IPv4, IPv6, alternate address forms, DNS changes, redirects, internal ranges, cloud metadata, and parser differences. A narrow allowlist of required destinations is usually easier to reason about.
How should redirects be handled?
Disable redirects unless the feature requires them. When redirects are allowed, set a small hop limit and apply the same scheme, hostname, port, DNS, address, and policy validation to every destination before connecting.
How should DNS be handled in SSRF prevention?
Resolve approved hostnames with a trusted resolver, evaluate all returned addresses, reject prohibited destination classes, and ensure the connection uses a destination that passed validation. Recheck changes and avoid a gap between validation and connection that could allow the destination to change.
How should webhooks be protected from SSRF?
Use approved destination patterns or verified customer-owned endpoints, restrict schemes and ports, validate every redirect, prevent access to internal networks, avoid returning raw destination responses, limit test requests and retries, and monitor destination changes.
How should cloud metadata services be protected?
Prevent fetchers from reaching metadata and management endpoints through network and process restrictions. Use cloud-specific protections such as token-based or authenticated metadata access where available, but treat them as defense in depth rather than the only SSRF control.
How can runtime monitoring detect SSRF?
Monitor server-side fetch features, destination category, resolved addresses, ports, redirect chains, validation results, blocked attempts, response size, timing, caller and tenant context, egress decisions, and telemetry health.
What should a SIEM-ready SSRF event contain?
Include the application, endpoint, caller, tenant, fetch feature, normalized destination category, scheme, port, redirect information, DNS and egress decision, response or callback evidence, confidence, affected scope, owner, and recommended action.
How should SSRF remediation be verified?
Repeat the authorized test using controlled destinations, validate original and redirected destinations, confirm prohibited networks are unreachable, test expected integrations, inspect egress and runtime evidence, and close only after the deployed behavior meets the acceptance criteria.
Detect risky server-side fetch behavior with runtime context
Ammune helps teams discover remote-fetch API features, analyze request and response behavior, identify unusual destinations and sensitive outcomes, forward SIEM-ready evidence, and support controlled remediation and operational handover.