Category: Web Exploits
Cross-site request forgery (CSRF) in the browser
Cross-site request forgery (CSRF) tricks a user’s browser into sending an authenticated request to a site without the user intending to.
Quick answer
If a user is logged in, CSRF can trigger actions like changing settings, initiating transactions, or granting access—especially on poorly defended apps.
For exploit chains and sandbox escapes, isolation moves untrusted web execution into an isolated container so the user’s device is not directly exposed to active web payloads.
When you need this
- You’ve seen indicators of this threat in your environment.
- Users frequently click unknown links as part of daily work.
- You need a control that reduces risk without relying on perfect user judgment.
Last updated
2026-01-29
How it usually happens in the browser
- A victim is authenticated to a target site in their browser.
- They visit an attacker-controlled page that submits a hidden request to the target site.
- The browser automatically includes the victim’s cookies with the request.
- If the app lacks CSRF protections, the action succeeds as if the user intended it.
What traditional defenses miss
- The request comes from the user’s browser and includes valid cookies—so it looks legitimate at a glance.
- Users may not see any UI change, especially if the attack is a background request.
- Security tools that focus on malicious binaries won’t catch a forged web request pattern.
How isolation changes the game
- Isolation reduces exposure to untrusted sites that launch CSRF attempts and makes those sessions disposable.
- However, CSRF is fundamentally mitigated by the application via tokens, same-site cookies, and origin checks.
- Isolation complements app controls by reducing how often users browse attacker-controlled pages on their endpoint.
Operational checklist
- For your apps: implement CSRF tokens, SameSite cookies, and origin/referrer validation.
- Require re-authentication for sensitive actions (payment and security changes).
- Isolate unknown browsing sources to reduce exposure to attacker-controlled pages.
- Use separate browser profiles or sessions for admin consoles when possible.
- Monitor for unusual bursts of sensitive actions that could indicate automated CSRF-like behavior.
FAQs
Does CSRF still work with modern browsers?
Many browsers and frameworks add protections (like SameSite cookies), but CSRF is still possible if apps are misconfigured or use legacy patterns.
Is CSRF the same as XSS?
No. XSS injects script into a site. CSRF forges requests from outside the site using the victim’s authenticated browser context.
Can isolation prevent CSRF?
It reduces exposure to attacker-controlled pages, but the core mitigation is application-side CSRF defenses.
What’s a high-risk CSRF action?
Anything that changes security settings, adds new OAuth apps, or initiates transfers/transactions is high risk.
References
- OWASP: Cross-Site Request Forgery (CSRF) — OWASP
- Cloudflare: Browser Isolation — Cloudflare