Server-Side Request Forgery: Security Architect's Perspective (Part 2)

In Part 1 of this series, we examined SSRF from a developer's perspective, covering secure coding patterns, input validation, allow lists, DNS resolution checks, and HTTP client configuration in Java 25 and Spring 7. Those technical controls are necessary but not sufficient.

This part shifts focus from code to strategy. Security architects must translate vulnerability knowledge into organizational controls, risk frameworks, and measurable security programs. Knowing how to fix SSRF is one thing. Building systems and processes that prevent these vulnerabilities from reaching production in the first place is the real challenge.

The program mechanics shared by every vulnerability class, including remediation SLAs, security gates, exposure windows, residual risk, developer enablement, and reporting, are covered in Building an Application Security Metrics Program: Measuring What Actually Matters. Rather than repeat them, this article applies that shared model and keeps the discussion specific to SSRF.

SSRF is CWE-918. The OWASP Top 10:2025 lists CWE-918 under A01:2025 Broken Access Control, which remains the number one category. The mapping reflects how SSRF is fundamentally an access control failure: the server accesses resources it should not be permitted to reach. SSRF can be critical in cloud environments, where exploitation may expose workload credentials or internal services. The resulting blast radius depends on network reachability and the permissions of any compromised identity.

Threat modeling for SSRF

Security architects must understand attack scenarios before designing controls. SSRF threat modeling identifies where vulnerabilities might exist, how attackers would exploit them, and what business impact would result.

Attack scenarios

Cloud metadata credential theft

This is one of the most severe SSRF scenarios in cloud environments. AWS EC2, Google Compute Engine, and Azure expose provider-specific metadata services over the link-local address 169.254.169.254; AWS can also expose an optional IPv6 endpoint. Depending on the provider and request capabilities, SSRF may retrieve AWS instance-role credentials, a Google service-account token, or an Azure managed-identity token. The token grants only the permissions assigned to that workload identity, but an overprivileged identity can expose data, secrets, or administrative APIs.

Business impact: Data breach, regulatory violations, and infrastructure takeover. Severity: High to Critical, depending on the reachable identity and its permissions.

Internal service reconnaissance

An attacker uses SSRF to probe internal networks, discovering services that are not exposed to the internet. They identify database ports, admin panels, monitoring dashboards, and other internal endpoints. This information guides subsequent attacks.

Business impact: Information disclosure enabling further attacks. Severity: High.

Internal service exploitation

After reconnaissance, the attacker targets vulnerable internal services. They might exploit an unpatched Redis instance, access an unsecured Elasticsearch cluster, or invoke internal APIs that lack authentication because they are not internet-facing.

Business impact: Data theft, service disruption, lateral movement. Severity: High to Critical depending on the target.

Denial of service through resource exhaustion

An attacker uses SSRF to force the application server to make many outbound requests to slow or non-responsive targets. This exhausts connection pools, threads, and memory, degrading or crashing the application.

Business impact: Service unavailability, customer impact. Severity: Medium to High.

STRIDE mapping

Applying the STRIDE threat model to SSRF:

Spoofing: The application makes requests that appear to originate from a trusted internal source, bypassing network-level access controls.

Tampering: Attackers can modify data in internal systems that lack authentication for internal traffic.

Repudiation: SSRF attacks may not be logged distinctly from legitimate traffic, making forensic analysis difficult.

Information Disclosure: Internal services, file contents when the client supports local protocols, and cloud workload credentials can be exposed.

Denial of Service: Resource exhaustion through forced outbound connections.

Elevation of Privilege: Workload credentials obtained via SSRF may enable privilege escalation when the attached identity has excessive permissions.

Attack tree analysis

A simplified attack tree for SSRF exploitation:

Understanding these paths helps prioritize controls at each stage.

2. Risk-based prioritization

Not all SSRF findings carry equal risk. Security architects must contextualize vulnerabilities based on exploitability and business impact.

CVSS contextualization

There is no standard CVSS score or score range for SSRF as a vulnerability class. Under CVSS v4.0, Base metrics describe the intrinsic severity of a specific vulnerability. Threat and Environmental metrics then account for factors such as current exploitation, deployment context, reachable assets, and the impact on the affected organization.

Factors that increase risk:

• Cloud deployment with metadata services enabled

• Application has network access to sensitive internal services

• No egress filtering in place

• Broad permissions assigned to cloud workload identities

• Application processes sensitive data (PII, financial, healthcare)

Factors that decrease risk:

• Strong network segmentation limiting internal reachability

• Cloud metadata service hardened and unreachable from workloads that do not need it

• IMDSv2 required on EC2, where the SSRF primitive cannot control the required method and headers

• Egress filtering restricts outbound connections

• Application runs in isolated network segment

• No sensitive internal services reachable

SSRF-specific risk worksheet

A practical risk scoring approach for SSRF:

Factor	Low (1)	Medium (2)	High (3)
Exploitability	Complex bypass required	Standard techniques work	Trivially exploitable
Internal Reach	Limited to DMZ	Some internal access	Full internal network
Cloud Identity Impact	No identity endpoint reachable	Hardened endpoint and narrow identity	Token reachable and broad permissions
Data Sensitivity	Public data only	Internal data	PII/financial/regulated
Business Criticality	Non-critical system	Supporting system	Core business system

Risk score = Sum of factors (5-15 range)

This score is a relative prioritization aid, not a CVSS replacement or a universal severity scale. Calibrate thresholds against the organization's environment and apply the remediation SLAs and exception process already defined in the application security metrics program.

3. Security architecture controls

Beyond code-level fixes, security architects must design infrastructure and process controls that provide defense in depth.

Network egress filtering

Restrict outbound connections from application servers. Most applications need to connect to a limited set of external services.

Implementation approach:

1. Inventory all legitimate outbound connections

2. Configure egress gateways, firewalls, security groups, or proxies to allow only those destinations

3. Use host or workload-level controls to block provider metadata endpoints where they are not needed

4. Block private, loopback, link-local, and other internal address ranges unless specifically required

5. Monitor and alert on blocked connection attempts

Effectiveness: Egress filtering can prevent requests to destinations outside the allow set and sharply reduce the blast radius. It does not remove the vulnerability, and an attacker may still abuse a destination the workload is legitimately allowed to reach.

Cloud metadata service hardening

For AWS EC2, require IMDSv2 on existing instances and enforce the same policy through account-level regional enforcement, AMIs, and launch templates. Account-level defaults alone can be overridden at launch and do not change existing instances:

# Require IMDSv2 on one existing EC2 instance
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

IMDSv2 requires a token obtained with a PUT request, followed by a metadata GET carrying that token in a header. This blocks GET-only and custom-header-limited SSRF, but it is not a guarantee when the attacker controls arbitrary methods and headers. Configure the response hop limit separately and use the lowest value compatible with the deployment. AWS notes that a hop limit of 1 can prevent container workloads from receiving the token response and recommends considering 2 in container environments.

Google Compute Engine requires the Metadata-Flavor: Google header and rejects requests carrying X-Forwarded-For. Azure IMDS requires Metadata: true and also rejects X-Forwarded-For; its managed-identity endpoint can return an Azure access token. These provider-specific request requirements raise the bar for limited SSRF primitives, but they do not replace metadata reachability controls, workload identity least privilege, or monitoring.

Network segmentation

Design network architecture that limits SSRF blast radius:

Tier isolation: Separate web tier, application tier, and data tier into distinct network segments with controlled access between them.

Service mesh: Implement service authentication and authorization, often including mutual TLS. Reaching an internal endpoint is then insufficient unless the forged request can also present an accepted identity and pass authorization. If the vulnerable client automatically receives a trusted credential, mTLS alone does not stop exploitation.

Zero trust principles: Do not assume internal traffic is trusted. Require authentication and authorization for all service-to-service communication.

DNS-level controls

Implement DNS-based protections:

Split-horizon DNS: Internal services should not be resolvable from internet-facing applications unless specifically required.

DNS monitoring: Log and alert on DNS queries from application servers. Queries for internal hostnames or unusual patterns may indicate SSRF probing.

Private DNS zones: Associate internal zones only with networks that need them, reducing unnecessary service discovery from internet-facing workloads.

DNS controls are supporting signals and exposure-reduction measures. They do not stop literal IP targets, a reachable metadata address, or DNS rebinding by themselves; resolved-address validation, connection pinning, and egress enforcement remain necessary.

4. Compliance mapping

SSRF vulnerabilities have implications for multiple compliance frameworks.

PCI DSS 4.0.1

The current PCI DSS version is 4.0.1. It does not name SSRF as a separate attack class, so the mapping depends on the in-scope system and control objective:

• Requirement 6.2.4 requires software engineering techniques or other methods to prevent or mitigate common software attacks in bespoke and custom software. SSRF controls support its access-control and business-logic attack categories more directly than the obsolete claim that SSRF is simply an injection flaw.

• Requirement 1.3.2 permits only necessary outbound traffic from the cardholder data environment and requires all other traffic to be denied. Default-deny egress for URL-fetching workloads directly supports that objective.

• Requirement 11.4 covers internal and external penetration testing. SSRF scenarios, metadata reachability checks, and segmentation validation can form part of the evidence when the tested system is in scope.

Evidence for auditors: Document the relevant SSRF test cases, URL-to-network data-flow analysis, approved outbound destinations, egress policy tests, and remediation evidence.

SOC 2

The current criteria are the AICPA 2017 Trust Services Criteria with revised Points of Focus 2022.

• CC6.6 covers protection against threats from outside the system boundaries. SSRF prevention, egress restrictions, and internal authorization can support that control.

• CC7.1 covers detecting configuration changes that introduce vulnerabilities and susceptibility to newly discovered vulnerabilities. SSRF-focused SAST, DAST, review, and remediation evidence support it.

• CC7.2 covers monitoring system components for anomalous events. Outbound-connection, URL-validation, and credential-use signals are the SSRF-specific evidence.

• CC7.3 through CC7.5 cover evaluating security events, responding to incidents, and recovery.

Evidence for auditors: Provide the SSRF rule configuration, scan and test results, egress policy, alert logic, incident exercises, and closed remediation records.

GDPR

Under the official GDPR text, exploited SSRF constitutes a personal data breach under Article 4 (12) only when it causes accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. If that threshold is met:

• Article 33 (1) requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in a risk to people's rights and freedoms.

• Article 33 (5) requires the controller to document all personal data breaches, including their facts, effects, and remedial action. This is breach documentation, not the Article 30 record of processing activities.

• Article 34 requires notification to affected data subjects without undue delay when the breach is likely to result in a high risk to their rights and freedoms, subject to the Article's exceptions.

Mitigation documentation: Show that technical measures (egress filtering, input validation) reduce likelihood and impact of SSRF-related breaches.

5. SSRF-specific program integration

SSRF prevention must be woven into the organization's security program, not treated as isolated fixes. The shared four-gate model, remediation governance, and reporting cadence come from the application security metrics program; the additions below are specific to user-influenced outbound requests.

Secure SDLC integration

Requirements phase: Security requirements should explicitly address SSRF. For any feature involving outbound HTTP requests based on user input, define approved destinations, schemes, ports, redirect behavior, timeouts, and response-size limits.

Design phase: Architecture reviews should evaluate SSRF risk. Questions to ask:

• Does this feature accept URLs from users?

• What internal resources could be accessed if validation fails?

• Is egress filtering in place for this component?

• Can the workload reach a provider metadata service, and what permissions does its identity have?

Development phase: Provide developers with approved SSRF validation libraries. The SsrfGuard component from Part 1 should be a shared library, not copy-pasted code.

Testing phase: Include SSRF in security test cases. Automated and manual testing should cover redirects, alternate IP forms, IPv6, DNS rebinding, metadata endpoints, and blind callbacks in authorized environments.

Deployment phase: Verify egress filtering and metadata controls with tests, not configuration review alone. Infrastructure-as-code should enforce approved outbound paths and provider-specific metadata policy.

SSRF checks at each gate

Apply the shared gates to SSRF-specific evidence:

Pre-commit: IDE plugins and hooks can flag request data flowing into network clients or URL-opening sinks. URI.create(...).toURL() is not a vulnerability by itself; the dangerous pattern is untrusted input reaching a fetch operation without the approved guard.

Pull request: SAST should follow user-controlled URL data into RestClient, WebClient, HttpClient, or lower-level connection sinks. Reviewers should require the shared guard, hardened client, and tests for bypass cases.

Pre-deployment: DAST and controlled out-of-band tests in staging should exercise each URL-shaped input, including stored webhook and callback flows.

Runtime: Application validation and egress policy are enforcement points. WAF rules may flag obvious internal IPs or metadata URLs as detection signals, but they cannot reliably determine the final destination after parsing, DNS resolution, or redirects.

SSRF training and exceptions

Training should teach developers to recognize URL fetchers, webhooks, callbacks, import-from-URL features, and rendering engines as outbound trust boundaries. Teams should know how to use the approved guard and how to request a reviewed exception when a legitimate feature cannot use a fixed destination allow list. Exception review should record the required destinations, identity permissions, redirect behavior, DNS and IP controls, response limits, and egress policy.

SSRF-specific metrics

The general definitions of MTTD, MTTR, vulnerability density, exposure window, residual risk, and security debt already live in the application security metrics program. Add the following SSRF-specific measures to that program, with an explicit inventory and denominator for each one.

Outbound sink inventory coverage

Percentage of components with user-influenced URL handling whose fetch sinks, owners, approved destinations, and reachable network zones are recorded in the threat model.

Approved guard coverage

Percentage of identified user-influenced fetch sinks that use the shared SSRF guard and a hardened client with redirects disabled, bounded responses, and connection-level protection against DNS rebinding.

Egress enforcement coverage

Percentage of in-scope workload tiers with a tested default-deny outbound policy and documented exceptions. Measure deployed enforcement, not the presence of an infrastructure-as-code rule in a repository.

Metadata isolation and hardening

For AWS, track the percentage of EC2 instances that require IMDSv2 and the percentage of workloads that do not need metadata and are proven unable to reach it. For Google Cloud and Azure, track unnecessary metadata reachability and the privilege of service accounts or managed identities that a vulnerable workload could obtain.

SSRF security-test coverage

Percentage of user-influenced fetch surfaces tested for redirects, alternate IP encodings, IPv6, DNS rebinding, metadata endpoints, internal address ranges, and blind callbacks. Track which bypass class found each defect so missing test depth is visible.

7. SSRF incident response considerations

Despite prevention efforts, SSRF exploitation may occur. Prepare for effective response.

Detection indicators

SSRF attacks may be detected through:

Network monitoring: Unusual outbound connections from application servers, especially to metadata IP ranges, internal networks, or unexpected external hosts.

Application logs: URL validation failures, error messages indicating failed internal connections, unusual URL parameters.

Metadata telemetry: Host firewall, container, proxy, eBPF, or network telemetry showing requests to provider metadata endpoints. Do not assume cloud control-plane audit logs record the original link-local HTTP request.

Cloud identity activity: CloudTrail, Cloud Audit Logs, and Azure activity or resource logs may show subsequent API calls made with a stolen workload identity. Look for new source locations, unusual services, privilege changes, data access, or token use outside the expected workload.

AWS GuardDuty: UnauthorizedAccess:EC2/MetadataDNSRebind can flag an EC2 DNS lookup that resolves to the metadata address. The UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS and .OutsideAWS findings can flag instance credentials used from another AWS account or an external IP address.

WAF alerts: Requests containing internal IP addresses, localhost references, or metadata URLs are useful triage signals, even when the WAF cannot prove the final connection target.

Response procedure

1. Confirm the event and preserve application, DNS, proxy, firewall, host, identity, and cloud API evidence with synchronized timestamps.

2. Identify the vulnerable fetch surface and contain it. Disable the feature or apply egress denial when possible; a temporary WAF rule can reduce known input patterns but should not be the only containment.

3. Determine which destinations were reached, which responses were returned to the attacker, and whether stored callbacks or background jobs can trigger additional requests.

4. If metadata or another credential source may have been reached, revoke or replace the workload identity session where the platform permits, rotate exposed static secrets, and reduce the identity's permissions.

5. Review cloud and internal-service audit logs for actions performed with the affected identity, including data reads, secret access, persistence, and privilege changes.

6. Scope any exposed data and invoke legal, privacy, and regulatory assessment based on confirmed facts, including the GDPR thresholds above where personal data is involved.

7. Repair the sink with the shared guard and hardened client, close the network path, and retest the exact payload and related bypass classes before restoring the feature.

8. Hunt for sibling sinks in webhooks, URL imports, previews, file fetchers, and PDF or image renderers that share the same component or design pattern.

After recovery, add the observed destination and bypass technique to the threat model, regression suite, detection logic, and shared guard. Feed the incident's generic timing and risk measures into the existing metrics program rather than creating a separate SSRF reporting process.

8. Vendor and third-party risk

SSRF risk extends to third-party components:

• Evaluate URL parsers, HTTP clients, rendering engines, and import libraries for redirect, proxy, DNS resolution, protocol, and response-limit behavior.

• Assess SaaS vendors that accept webhook URLs, import remote content, generate previews, or render user-supplied documents.

• Ask vendors whether user-controlled fetches use destination allow lists, resolved-IP validation, redirect restrictions, metadata isolation, egress policy, and blind-SSRF testing.

• Confirm how vendor workload identities are scoped if a fetcher can reach cloud metadata.

• Monitor third-party dependencies for SSRF vulnerabilities and retest the consuming feature after relevant upgrades.

Wrapping part 2

SSRF prevention is not merely a coding problem. It is a security program challenge that spans architecture, governance, process, and culture.

Security architects must think beyond individual vulnerabilities to systemic controls. For SSRF, that means inventorying every user-influenced outbound request, limiting what each workload can reach, hardening provider metadata access, constraining workload identity permissions, and testing the bypasses that simple URL checks miss.

SSRF defense reflects a maturity journey across two perspectives:

1. Developer perspective: Understand the vulnerability and implement secure code patterns

2. Security architect perspective: Design controls, measure effectiveness, and integrate security into organizational processes

The technical foundations from Part 1 provide the application-layer controls. The architecture, cloud hardening, SSRF-specific measurements, and response checks here apply those controls at system scale, while the shared application security metrics program supplies the organization-wide governance without duplicating it in every vulnerability article.