On-Site Request Forgery is a web attack where a malicious page causes a victim’s browser to send a same-site request the application treats as authorised. It works by abusing the browser’s existing session cookies or other ambient credentials, so actions such as state changes can happen without the user’s intent.
How On-Site Request Forgery Works
On-Site Request Forgery is a browser-driven attack that relies on the victim already being authenticated to the target site. The malicious page does not need to steal the session; it persuades the browser to send a same-site request that the application may accept because the browser automatically attaches ambient credentials.
The core security problem is trust in browser state rather than explicit user intent. When the application treats an ordinary in-session request as authoritative, an attacker can trigger actions that look legitimate to the server even though the user never meant to perform them.
Why It Is Dangerous
OSRF is dangerous because it turns a normal browser session into an abuse path for state-changing actions. If the application accepts requests purely because they arrive with valid cookies or other ambient credentials, attackers can cause transfers, preference changes, approvals, or other privileged actions without ever knowing the password.
The attack is especially effective where the application assumes same-site traffic is inherently trustworthy. That assumption is brittle in modern browser environments, because same-site context is not the same thing as user consent, and ambient credentials can be replayed by the browser automatically.
For broader context on browser-mediated request abuse, see the Web Application Attacks Guide.
Common Exposure Points
Exposure usually appears in applications that expose state-changing endpoints without a strong request-origin check or a separate anti-forgery control. Any feature that performs sensitive actions from a browser session, especially when it relies on cookies alone, deserves scrutiny.
High-risk patterns include workflows that are reachable with a simple POST or GET, endpoints that accept ambient authentication but no user-specific proof, and designs that assume the browser will only send requests the user intended. CSRF-style defenses often apply here too, but the key question is whether the application is verifying intent, not just session validity.
Because many same-site request abuses overlap with broader server-side request forgery concerns in web applications, the SSRF Prevention Guide is useful where the application also performs URL fetches or other outbound requests.
How Defenders Reduce the Attack Surface
Defensive design starts by requiring an explicit signal that the request came from the intended application flow. That usually means validating origin or fetch metadata, using per-request anti-forgery tokens, and ensuring state changes are not accepted from unsafe cross-site contexts.
Session protections also matter. Cookies should be configured so that cross-site request delivery is constrained where possible, and sensitive operations should require reauthentication or step-up checks when the business impact is high. Where the application makes external requests as part of the workflow, outbound allowlisting and URL validation help prevent adjacent request-abuse paths.
For practical defence patterns, review the CSRF Prevention Guide and the Fetch Metadata and Resource Isolation Policy Guide.
Risk and Threat Considerations
On-Site Request Forgery matters because it converts a valid browser session into an untrusted control channel. The main risk is unauthorised state change, but the deeper threat is that the server may treat browser-supplied ambient credentials as proof of intent when they only prove that a session exists.
Failure mechanism: The attacker places a victim in a context that causes the browser to send a same-site request with authenticated cookies or other ambient credentials, and the application accepts the request without a separate anti-forgery check.
Impact: Actions can be executed without the user’s consent, which can lead to account changes, transaction abuse, privilege changes, or chained compromise when a single trusted request alters security settings.
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 | OSRF-style abuse often exploits browser-authenticated flows and token handling. |
| Recommendation — Verify browser-authenticated flows with explicit anti-forgery and state validation. | ||
| NIST SP 800-53 Rev 5 | AC-10 — Concurrent Session Control | OSRF abuses active browser sessions and ambient authentication state. |
| IA-5 — Authenticator Management | OSRF relies on cookies and other ambient credentials that represent active authentication state. | |
| Recommendation — Limit session misuse by enforcing stronger controls on sensitive in-session actions. Manage session-related authenticators so they cannot be reused to authorize unintended actions. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | OSRF succeeds when authenticated requests can change objects or state without intended authorization checks. |
| API5 — Broken Function Level Authorization | OSRF can trigger privileged functions through a trusted browser session. | |
| Recommendation — Enforce object-level authorization on every state-changing request. Restrict sensitive functions so session presence alone never grants execution. | ||
Practitioner Guidance
What to watch for: Focus on any browser-facing action that changes state, especially if it works solely because the user is already signed in. If a request would still succeed when replayed from an unintended context, that flow needs stronger intent verification.
Practitioner takeaway: The safest mental model is that cookies authenticate a session, not a user action, so sensitive operations should only succeed when the application can verify deliberate request intent.
Related resources from NHI Mgmt Group
- Why do unauthenticated local AI agents create a bigger risk than a normal cross-site request forgery issue?
- What is the difference between cross-site scripting and cross-site request forgery in JavaScript applications?
- What happens when cross-site request forgery is present in a system that already has weak input handling?
- How should security teams prioritise cross-site scripting, server-side request forgery, and account takeover findings from bug bounty reports?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org