What Is Cross-Site Request Forgery (CSRF)?
If you are asking what threat does a cross site request forgery present, the short answer is this: CSRF lets an attacker make a victim’s browser send an unwanted request to a trusted web application while the victim is already signed in. The browser includes the user’s session automatically, so the server may treat the request as legitimate.
That is why CSRF still matters. It does not need the attacker to know the user’s password, and it does not depend on breaking HTTPS. It abuses trust between the browser, the authenticated session, and the web app.
This guide explains what is csrf (cross-site request forgery) and how does it work?, where it shows up, how to detect it during review and testing, and how to stop it with controls that actually hold up in production. It is written for developers, security teams, IT managers, and technical readers who need a practical answer, not theory.
CSRF is a request-forgery problem, not a password problem. If the application cannot reliably tell whether a state-changing request came from the real user or from another site, the browser will happily do the attacker’s work for them.
Understanding Cross-Site Request Forgery
Cross-Site Request Forgery is a web attack that relies on browser trust. When a user logs in to a site, the browser stores session information, usually in cookies. After that, the browser often sends those cookies automatically with requests to the same site, even if the request was triggered from somewhere else.
That automatic behavior is what makes CSRF possible. The attacker does not need to steal the session cookie in many cases. They only need to cause the victim’s browser to send a request that changes data or performs an action on a site where the user is already authenticated.
CSRF vs. XSS
CSRF is often confused with cross-site scripting, but the two problems are very different. XSS injects malicious script into a site and runs in the victim’s browser under that site’s origin. CSRF does not require script execution on the target site. It abuses the browser’s willingness to attach credentials to a request.
That distinction matters for remediation. XSS is often fixed by sanitizing output and controlling script execution. CSRF is fixed by verifying request intent with anti-CSRF tokens, SameSite cookies, and server-side checks.
| CSRF | XSS |
| Forces a victim’s browser to send an unwanted request | Injects script that runs in the victim’s browser |
| Relies on authenticated sessions and browser auto-sending cookies | Relies on unsafe input handling and script execution |
| Common targets include email changes, profile updates, and payments | Common targets include session theft, data exfiltration, and page manipulation |
CSRF remains dangerous even with strong passwords and HTTPS. A secure login does not stop a forged request after login. If an attacker can trick a user into loading a malicious page, the browser may still send a valid session cookie to the target application.
Examples of actions attackers commonly target include:
- Changing account email addresses to take over recovery workflows
- Updating profile details such as phone numbers or mailing addresses
- Triggering fund transfers or payment submissions in financial applications
- Modifying admin settings in internal portals
- Changing password reset options or security questions
For a deeper technical baseline on web application defense, OWASP’s guidance on the OWASP Top 10 is a useful reference, and the OWASP CSRF Prevention Cheat Sheet provides implementation detail that maps directly to real application code.
How a CSRF Attack Works Step by Step
A CSRF attack usually begins after the victim has already authenticated to a trusted site. The attacker does not need to break into the account. They only need a way to make the user’s browser submit a request to that site while the user still has a valid session.
- The victim logs in to a site such as an email portal, shopping account, or admin console.
- The attacker lures the victim to a malicious page, ad, message, or link.
- The malicious page triggers a request to the target application, often using a hidden form or image request.
- The browser automatically includes the session cookie because it belongs to the target site.
- The server processes the request as if the user initiated it, if no CSRF defenses are in place.
Imagine a user who is signed in to a banking portal in one tab and later visits a malicious page in another tab. If the banking site accepts a request to change a payee or submit a transfer without validating intent, the browser may send the authenticated request silently. The victim may see no warning at all.
Warning
CSRF often produces no obvious error message, pop-up, or visible sign of compromise. The user may only discover the damage later when an email address, password reset setting, or payment destination has already changed.
The attack works because the server trusts the session, not because the attacker knows credentials. That is a subtle point, but it is the center of the problem. The app must prove that the request came from the user’s own interaction, not merely from a browser that happens to be logged in.
For session and cookie handling details, vendor guidance such as Microsoft Learn and platform documentation from MDN Web Docs are useful because they document browser behavior and server-side expectations without guesswork.
Common CSRF Attack Vectors and Techniques
Attackers use whatever the browser will send without much friction. The most common CSRF vectors are simple, which is part of what makes them effective. They do not need a complex payload if the target application has weak request validation.
Common delivery methods
- Malicious links that trigger state-changing requests when opened
- Hidden HTML forms that auto-submit when the page loads
- Image tags that send a request when the browser fetches the source URL
- Iframes used to load or trigger a request in the background
- Redirect chains that hide the real destination from the user
These methods can be paired with social engineering. A user may be told to view an invoice, confirm delivery, or check an account notice. If the page is crafted to submit a request to another site in the background, the browser may execute the attacker’s intended action automatically.
Multi-step workflow abuse is especially useful when applications have poor state tracking. For example, an attacker may try to manipulate a password reset flow, an account recovery page, or an admin settings screen that assumes the user already completed some prior step. If the application does not bind each step to the correct user intent, the workflow can be abused.
Modern browser behavior and framework defaults reduce some old-school vectors, but they do not eliminate risk. Developers sometimes assume “browsers block that now,” which is not a safe security strategy. The real control is server-side validation of request origin and authenticity.
Note
CSRF succeeds because the browser is doing exactly what it was designed to do: send cookies and session data with requests to a trusted site. The browser is not compromised. The trust model is.
For additional context on browser and request behavior, MDN’s HTTP documentation and the RFC repository are good sources for request semantics and cookie-related standards.
Why CSRF Still Matters in Modern Web Applications
It is easy to assume CSRF is a legacy issue because many frameworks ship with protections now. In practice, the threat remains relevant because applications are built from mixed components, old endpoints, custom APIs, and workarounds that bypass default protections.
HTTPS protects traffic in transit, but it does not tell the server whether a request was intentional. MFA helps with login, but it does not stop an already authenticated session from being abused. Firewalls also do not help much when the request comes from a legitimate browser to a legitimate public endpoint.
Why sessions increase exposure
Long-lived sessions increase the window of opportunity. If a user stays signed in all day, the attacker has more time to get the browser to send a forged request. Shared workstations, browser sync, and mobile sessions can extend that risk further.
Legacy applications are another problem. Old code often uses GET requests for destructive actions, lacks anti-CSRF tokens, or trusts referrer data alone. Framework upgrades can also introduce gaps when old custom endpoints were not migrated to secure defaults.
Operationally, CSRF can cause account takeover, fraud, support incidents, and reputation damage. If an attacker changes a customer’s contact details, recovery settings, or payout destination, the business may have to clean up the results long after the original request happened.
The relevance of this issue is also reflected in broader web security research and industry reports. The OWASP Top 10 continues to highlight access control and request validation as recurring application risks, and the Verizon Data Breach Investigations Report regularly shows how web application weaknesses and social engineering combine in real incidents.
A strong login does not equal a secure transaction. If the application cannot distinguish a genuine click from a forged request, any authenticated browser session becomes a potential attack surface.
Identifying CSRF Vulnerabilities in Applications
CSRF vulnerabilities usually show up in requests that change state. Read-only requests are less risky because they do not alter data or trigger sensitive workflows. The higher the impact of the action, the more carefully it should be protected.
Endpoints to review first
- Update profile pages
- Change email or phone number forms
- Password change workflows
- Payment submission or fund transfer endpoints
- Delete account actions
- Admin role changes and permission updates
- API endpoints that create, update, or delete records
One of the easiest red flags is a state-changing GET request. GET should be safe and idempotent in a proper design. If a GET endpoint changes settings, sends money, or deletes data, it is a major risk and should be treated as a defect.
Other signs of weakness include missing anti-CSRF tokens, predictable request parameters, inconsistent behavior between forms and APIs, and endpoints that rely only on cookie presence. Internal tools and low-visibility admin pages are especially easy to overlook, which is why they deserve the same review as public-facing features.
Developers should review forms, APIs, and workflows together. A site may protect the main HTML form but forget the AJAX endpoint used by the same page. That kind of partial protection gives a false sense of security.
For standards-driven application review, NIST guidance such as NIST CSRC and the CIS Benchmarks are helpful references for hardening practices and secure configuration baseline thinking.
Key Takeaway
Any endpoint that changes state should be assumed vulnerable until it proves otherwise with token validation, safe HTTP methods, and server-side checks.
How to Detect CSRF During Testing and Review
CSRF testing starts with a simple question: can a request be made from another origin and still succeed without proof that the user intentionally submitted it? If the answer is yes, the application may have a problem.
Manual testing approach
- Log in to the target application in a browser.
- Capture a state-changing request using browser developer tools or a proxy.
- Replay the request from a different origin without the anti-CSRF token.
- Observe the result and verify whether the server rejects it.
- Repeat across workflows such as profile changes, password resets, and settings updates.
Use browser developer tools to inspect form fields, request headers, cookies, and methods. If you do not see a token, that is a clear signal to investigate further. If a token exists but the server does not validate it, the protection is only cosmetic.
Automated scanners can help as a first pass, especially for finding obvious missing tokens or unsafe methods. They should not be treated as complete validation. Many CSRF issues are workflow-specific, meaning a scanner might miss a multi-step action or a request hidden behind JavaScript.
Test edge cases too. Check behavior when the session is expired, when the token is reused, when the request is sent from another browser, and when a page is loaded in a different site context. Also verify consistent behavior across browsers, since cookie handling and SameSite behavior can differ slightly in practical use.
For testing methodology and secure implementation references, the PortSwigger Web Security Academy CSRF materials are widely used by practitioners, and the official OWASP CSRF Prevention Cheat Sheet maps well to test cases.
CSRF Prevention Techniques That Actually Work
The strongest CSRF defense is layered. Do not depend on a single control and assume the issue is solved. The most effective combinations are anti-CSRF tokens, secure cookie settings, safe HTTP methods, and server-side validation of request origin.
Controls that matter most
- Anti-CSRF tokens to verify request intent
- SameSite cookies to limit cross-site credential sending
- POST, PUT, PATCH, and DELETE for state-changing actions
- Origin and Referer validation as additional checks
- Re-authentication for highly sensitive actions
Anti-CSRF tokens are one of the most reliable controls because they tie a request to the authenticated session and the user’s own form or script action. SameSite cookies help by reducing how often browsers send cookies in cross-site scenarios, but they are not enough on their own. Some workflows still need explicit server-side verification.
Safe HTTP methods matter because they make request intent clearer and reduce dangerous side effects. If a delete action uses GET, any link or image request could become a problem. If it uses POST with token validation, the server has a much better chance of rejecting forged input.
Origin and Referer checks are useful extra signals, especially when tokens are missing or when a framework supports layered validation. They should be treated as defense-in-depth, not as the primary control. Headers can be absent or altered by privacy tools, so the server should not rely on them alone.
For vendor and platform guidance, the official documentation from Microsoft Learn, MDN Web Docs, and OWASP is the best starting point because it reflects real browser and application behavior.
Implementing Anti-CSRF Tokens Correctly
A good anti-CSRF token is unpredictable, tied to the user session, and checked on every sensitive state-changing request. If any one of those elements is missing, the protection weakens quickly.
How token handling should work
- Generate a random token using a secure source of entropy.
- Associate the token with the user session or request context.
- Place the token in a hidden form field or a custom request header.
- Validate the token server-side before processing the action.
- Reject the request if the token is missing, invalid, expired, or reused incorrectly.
In traditional server-rendered applications, hidden form fields are common. In AJAX or single-page applications, developers often send the token in a custom header such as X-CSRF-Token. The exact name is less important than consistency and validation.
Common mistakes include reusing tokens too broadly, embedding them where third-party scripts can read them unnecessarily, or validating them on some endpoints but not all. Another common failure is protecting only web forms while leaving JSON endpoints open. Attackers will use whichever route is least protected.
Token enforcement should be consistent across the entire application. That includes admin panels, mobile APIs, background jobs that expose write endpoints, and any endpoint that performs a state change. A partial rollout can leave the most sensitive path exposed.
If the server does not validate the token every time, the token is just decoration. CSRF defenses only work when the application fails closed.
Frameworks often provide built-in helpers for this. The correct implementation depends on the stack, but the principle does not change: every sensitive request must prove intent before the action is accepted.
Using SameSite Cookies and Browser Protections
SameSite cookies tell browsers when to send cookies in cross-site contexts. That makes them a useful line of defense against CSRF because many forged cross-site requests will not include the session cookie the attacker is hoping for.
SameSite modes in practice
| Strict | Strongest restriction; cookies are not sent in most cross-site contexts, but this can break some legitimate workflows. |
| Lax | More practical for many applications; cookies are usually sent on top-level navigations but blocked in many cross-site subrequests. |
| None | Cookies are sent cross-site, which requires Secure and should be used only when cross-site behavior is truly needed. |
SameSite is helpful, but it is not a complete CSRF defense. Some flows still require cross-site behavior, such as certain identity provider redirects or embedded integrations. In those cases, the application must still rely on anti-CSRF tokens and validation checks.
When adjusting cookie behavior, test the real workflows first. A change that looks secure on paper can break login redirects, payment handoffs, or SSO flows if it is applied without planning. Use Secure cookies and HTTPS everywhere. That is table stakes, not optional hardening.
Pro Tip
Use SameSite as a risk reducer, not as the only gate. The safest pattern is still token validation plus safe request methods plus cookie hardening.
Browser protections are useful because they reduce exposure in common scenarios. They should not replace server-side validation, because the server ultimately decides whether the action is valid. The application must enforce intent even when a browser behaves differently than expected.
For official browser guidance, MDN’s cookie documentation is the clearest reference for practical SameSite behavior.
Secure Design Practices for Developers
Good CSRF defense starts in the design phase, not after a security bug is reported. Developers should make unsafe requests hard to build and easy to spot during review.
Design habits that lower CSRF risk
- Avoid state-changing GET endpoints
- Separate read-only actions from write operations
- Require re-authentication for sensitive changes such as email, password, or payout updates
- Protect APIs with the same discipline as HTML forms
- Use framework defaults instead of custom homegrown defenses when possible
Re-authentication is especially useful for high-impact actions. If a user is changing the account recovery email or approving a payout destination, the system should ask for proof of fresh intent. That can be a password prompt, a second factor, or another step appropriate to the risk.
APIs deserve special attention because teams often secure the web UI and forget the backend endpoint that powers it. A JSON API used by JavaScript can still be CSRF-prone if it accepts cookie-based authentication without proper validation.
Code review and threat modeling help catch weak assumptions early. Ask practical questions: Does this endpoint mutate data? Does it rely on cookies? Can it be triggered from a different origin? Is there any request that should require a token but does not?
Standards and secure development guidance from NIST and architecture-focused references like ISO/IEC 27001 are useful for building a process that treats request validation as part of security governance, not as an afterthought.
CSRF in Real-World Business and Security Contexts
CSRF is not just a technical flaw. It can become a business problem fast. An attacker who changes contact details, banking details, shipping addresses, or recovery settings can trigger fraud, customer support load, and incident response work.
In regulated environments, the consequences can be worse. Financial services, healthcare, and e-commerce applications often store high-value data and trigger sensitive workflows. A forged request that changes an address or contact method may interfere with fraud controls, account recovery, or compliance obligations.
Business impact examples
- Fraud through unauthorized transfers or payment changes
- Account takeover support cases after recovery settings are changed
- Operational overhead from manual remediation and customer verification
- Trust erosion when users see changes they did not make
- Incident response costs tied to investigating the root cause and scope
CSRF can also be one step in a broader attack chain. For example, an attacker might first use social engineering to get a user to open a page, then rely on CSRF to change account settings, and finally use the new settings to complete account takeover. That is why “small” request-forgery issues can become major incidents.
Business leaders should care because prevention is cheaper than cleanup. Once a malicious request lands, the organization has to identify what changed, when it changed, who approved it, and whether other systems trusted that bad data downstream.
The broader risk picture is reflected in public workforce and incident data from sources such as the U.S. Bureau of Labor Statistics for security and software roles, and the Cybersecurity and Infrastructure Security Agency for current defensive guidance and threat awareness.
Best Practices for Ongoing CSRF Defense
CSRF defense is not a one-time configuration step. Applications evolve, frameworks change, and new endpoints get added. If the security checks do not evolve with the code, gaps appear quickly.
Operational practices to keep protection intact
- Test CSRF controls during development and before release.
- Retest after major changes to forms, APIs, authentication, or session handling.
- Keep frameworks and dependencies updated so built-in protections stay current.
- Train developers and QA to recognize risky workflows and unsafe methods.
- Monitor logs for suspicious bursts of account changes or unexpected write activity.
- Review cookie policy and session settings on a regular schedule.
Logging matters because it can help spot patterns such as repeated failed token checks, odd account changes from uncommon origins, or write actions that happen immediately after a suspicious referrer pattern. That data is useful both for detection and for incident analysis.
QA teams should not limit testing to the “happy path.” They should verify that sensitive actions fail safely when tokens are missing, methods are wrong, or requests are replayed from another origin. A good test plan includes browsers, session states, and edge-case workflows that look normal to users but are dangerous to attackers.
Framework updates also matter. Many platforms provide default CSRF protection, but only when configured correctly. If a custom API, alternate auth method, or legacy form bypasses those defaults, the protection gap is back.
For workforce and security program context, NIST NICE is a strong reference for the skills and roles involved in application security, and it supports a practical view of who should own review, testing, and remediation in an IT organization.
Conclusion
Cross-Site Request Forgery is a browser trust attack that forces an authenticated user’s browser to perform unwanted actions on a trusted site. That is why the primary answer to what threat does a cross site request forgery present is unauthorized state change: altered settings, changed recovery details, fraudulent transactions, or admin actions the user never intended.
The best defenses are straightforward when implemented correctly. Use anti-CSRF tokens, enforce safe HTTP methods, validate requests server-side, harden SameSite cookies, and add origin or referer checks as a second layer. For sensitive workflows, require fresh verification before the action is accepted.
If you own a web application, audit the endpoints that change data. If you manage a security program, make sure CSRF testing is part of standard review, not an occasional check. If you maintain legacy code, assume older forms and APIs are vulnerable until they are proven otherwise.
The practical takeaway is simple: build applications that can prove user intent, not just user presence. That is how you reduce CSRF risk and create web systems that are harder to abuse and easier to trust.
CompTIA®, Microsoft®, AWS®, ISC2®, and ISACA® are trademarks of their respective owners.