Request forgery is a security flaw where an attacker makes a trusted application send unwanted requests on their behalf. In practice, this often means abusing a server, browser, or agent’s authority to reach internal resources, trigger actions, or expose data without proper user intent or authorization checks.
How Request Forgery Works
Request forgery happens when an attacker causes a trusted component to make a request it would otherwise not make. The dangerous part is not the request itself, but the authority the component already has, which can turn a small input flaw into access to internal systems or sensitive data.
This pattern often appears when a server fetches URLs on behalf of users, a browser submits state-changing requests with ambient credentials, or an agent can reach internal APIs without strong intent checks. In each case, the forged request rides on an existing trust relationship rather than on direct attacker credentials.
Why Request Forgery Is Dangerous
Request forgery is dangerous because defenders often secure the front door while overlooking what their own application can reach behind it. That makes it useful for reaching internal metadata services, privileged APIs, administrative functions, or network locations that are not meant to be directly exposed.
The impact can range from data exposure to action abuse, including changes made under a legitimate session or service context. When the trusted component has broad network reach or elevated access, a single forged request can become an internal pivot point.
Common Request Forgery Patterns
Two patterns matter most. Server-side request forgery, or SSRF, uses a backend application to send attacker-chosen outbound requests. Cross-site request forgery, or CSRF, uses a victim’s authenticated browser session to submit an unwanted action to a web application. Both rely on a trusted sender being tricked into acting on the attacker’s behalf.
Request forgery also shows up in API integrations, agent tools, webhook handlers, and browser-based workflows where the receiver assumes that a request is legitimate because it arrived through a normal channel. The specific controls differ, but the core failure is the same: the system trusts the request source or context too much.
How Teams Reduce Exposure
Reducing exposure starts with identifying where your applications can send requests, what they can reach, and which actions are allowed without extra verification. That means reviewing outbound fetch logic, internal service reachability, browser session behavior, and any component that can act with inherited authority.
For SSRF, teams should constrain outbound destinations, validate and normalize target URLs, and limit access to internal ranges and metadata endpoints. For CSRF, they should require anti-forgery tokens, verify origin or fetch metadata where appropriate, and avoid relying on cookies or ambient credentials alone for sensitive state changes.
For request paths that carry identity or privilege, the key control question is whether the request is authenticated by design, or merely accepted because it arrived from a trusted place. If the second is true, the application is already assuming too much.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Request forgery often abuses authenticated browser flows and token-bearing requests. |
| Recommendation — Require anti-forgery checks and binding controls around browser-authenticated state changes. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Request forgery succeeds when a trusted component can perform actions beyond intended enforcement. |
| SI-10 — Information Input Validation | Request forgery is often enabled by unsafe handling of attacker-controlled URLs or parameters. | |
| Recommendation — Enforce authorization on the action actually requested, not just on the request source. Validate and restrict request targets, parameters, and redirect destinations before use. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Forged requests can trigger privileged API actions without proper function-level checks. |
| Recommendation — Verify that every privileged API operation is separately authorized before execution. | ||
Related resources from NHI Mgmt Group
- What is the difference between server-side request forgery and unsafe consumption of APIs?
- Why do unauthenticated local AI agents create a bigger risk than a normal cross-site request forgery issue?
- What are the signs that an unauthenticated server-side request forgery issue is present in a map styling or catalog tool?
- Why do server side request forgery flaws sometimes lead to local file reads?