CWE-918

What CWE-918 Means in Practice

CWE-918 describes server-side request forgery, a weakness where an attacker can influence a server into sending requests on their behalf. That matters because the server usually has access to internal networks, trusted services, and cloud metadata or control-plane endpoints that the attacker cannot reach directly.

SSRF is especially dangerous when the application accepts a URL, hostname, webhook target, image source, import location, or any other network reference from user-controlled input. Once that input is not strictly constrained, the server can become a proxy for scanning, data retrieval, or reachability into protected resources.

Why SSRF Is Dangerous

The core problem is not only that the application makes an outbound request, but that it makes it from a privileged network position. A successful SSRF can expose internal APIs, administrative interfaces, tenant isolation gaps, or metadata services that issue short-lived credentials and other sensitive secret material.

That makes SSRF a classic trust-boundary abuse. The application thinks it is fetching a harmless remote resource, while in reality it is following attacker-supplied instructions into places that were intended to be reachable only from inside the environment.

For broader weakness context, NHIMG’s CWE Top 25 Guide explains how SSRF fits into high-impact weakness patterns and why it is often grouped with other recurring input-handling and trust-boundary failures.

How Organisations Assess Exposure

Exposure review starts with identifying every feature that accepts a destination supplied by a user, partner, or workflow, then tracing where that destination can resolve. That inventory should include webhooks, document fetchers, URL previews, importers, PDF renderers, integration connectors, and any internal service that follows redirects or resolves network references dynamically.

Teams should also check whether the application can reach internal-only addresses, cloud instance metadata endpoints, or service discovery names from its runtime environment. Vendor advisories, product documentation, and architecture diagrams are important here because the practical risk depends on the exact network placement and the trust the application inherits.

For weakness mapping across software and platform records, the CVE, CWE and CPE Guide is useful when teams need to connect a weakness class like CWE-918 to concrete products and exposure management workflows.

Remediation and Defensive Controls

The safest design is to avoid arbitrary outbound fetching wherever possible. When URL-driven fetching is required, controls should constrain destinations to a strict allowlist, resolve names safely, block internal and link-local ranges, and prevent redirects from bypassing those checks.

Defensive depth also matters when a patch or code change is not immediately available. Network egress filtering, metadata service hardening, request brokering, response size limits, DNS safeguards, and service segmentation all reduce the blast radius if a request can still be induced.

Where the pattern appears in API and integration design, NHIMG’s OWASP API Top 10 API7 Server-Side Request Forgery Guide gives a control-oriented view of URL-consuming features, safe webhook design, and prevention testing.

Detection and Post-Exploitation Review

Detection is often difficult because SSRF requests may look like legitimate application traffic. Useful signals include unusual destination patterns, unexpected access to internal IP ranges, repeated failures against metadata endpoints, and request chains that do not match normal business workflows.

After suspected exploitation, review logs for outbound request destinations, proxy traces, unusual DNS lookups, and any evidence that internal responses were reflected back to a caller. If the weakness may have exposed secrets or temporary cloud credentials, treat the event as a possible foothold into the broader environment.

The OWASP Top 10 A01 Guide is also relevant because SSRF commonly overlaps with broken access control and confused-deputy style failure modes that broaden the impact of the initial request trick.

Risk and Threat Considerations

SSRF is risky because it converts a trusted server into an attacker-controlled network client. That can expose internal services, leak metadata credentials, and create a pivot point into systems that were never meant to be reachable from outside the trust boundary.

Failure mechanism: The application accepts attacker influence over a destination and then follows that destination using its own network access, privileges, and trust relationships. If redirect handling, DNS resolution, or internal address filtering is weak, the attacker can steer requests into protected resources.

Impact: The result can be internal information disclosure, credential exposure, service abuse, or a foothold for later movement into adjacent systems. In cloud environments, exposure of metadata or control-plane endpoints can turn a single input flaw into broader compromise.

Practitioner Guidance

What to watch for: Treat any feature that consumes a URL or host value as a security-sensitive control point, not a convenience function. The key judgement is whether the application genuinely needs arbitrary outbound reachability, or whether a narrow allowlist and fixed integration pattern would be safer.

Governance implication: Ownership should sit with the team that controls both the input surface and the network egress path, because SSRF risk is created by their combination. Security review should be required for features that can reach internal or cloud-managed endpoints, especially when they are exposed through uploads, webhooks, previews, or integrations.

Related resources from NHI Mgmt Group

• What do teams get wrong when they rely on top CWE rankings alone?
• Why do repeat CWE classes keep causing breaches even when teams know about them?
• How should security teams use the CWE Top 25 and OWASP Top 10 together without duplicating work?
• Why do CWE-level findings provide stronger audit evidence than OWASP category labels?