What Is Cross-Site Request Forgery (CSRF)?

Cross-site request forgery (CSRF) is a web attack that causes an authenticated user’s browser to send an unwanted request to an application. The application accepts the request because the browser automatically includes the user’s session cookie or another ambient credential.

CSRF targets state-changing actions such as updating an email address, changing settings, creating a transfer, adding an administrator, or connecting an account. The attacker does not need to read the response to cause harm.

Key Takeaways

• CSRF abuses the browser’s automatic inclusion of credentials in cross-site requests.
• State-changing actions need unpredictable tokens or equivalent request-bound validation.
• SameSite cookies reduce exposure but should be combined with origin checks and secure design.
• Cross-site scripting can bypass many CSRF defenses, so both weaknesses must be addressed.

How Cross-Site Request Forgery (CSRF) Works

A victim signs in and retains an active session. The attacker causes the victim to open malicious content that submits a request to the target, and the browser adds the target’s cookies automatically.

If the application checks only that the session is valid, it may perform the action as the victim. Simple requests can be triggered through forms or resource tags, while some APIs are exposed through cross-origin request behavior.

Common Types and Techniques

• Form-based forged state changes
• Login and account-linking CSRF
• Administrative or financial action forgery
• CSRF combined with XSS or weak cross-origin controls

Security and Business Risks

• Unauthorized profile, recovery, or permission changes
• Fraudulent transactions or destination changes
• Creation of API keys, integrations, or privileged accounts
• Abuse of trusted sessions without password theft

Warning Signs and Detection

Review unusual high-impact state changes, unexpected Origin or Referer values, repeated actions following external navigation, and affected-user reports. Application logs should identify the session, endpoint, prior state, and resulting change.

Prevention and Response

Use unpredictable session-bound anti-CSRF tokens, appropriate SameSite cookies, Origin validation, safe HTTP methods, and reauthentication for high-impact actions. Do not place tokens in URLs, and test legacy and alternative endpoints.

How SOCRadar Can Help

SOCRadar combines external asset visibility, threat intelligence, Dark Web monitoring, vulnerability context, and indicator enrichment to help teams identify exposure and investigate activity connected to cross-site request forgery.

Explore SOCRadar Attack Surface Management or request a demo to strengthen threat-informed prevention and investigation.

Frequently Asked Questions

What Does an Attacker Need for a CSRF Attack to Succeed?

Three conditions have to line up: the victim holds an active, authenticated session with the target application; the action relies on the session cookie alone as proof of intent; and the attacker can induce the victim’s browser through a form, image tag, or link to submit the request. If the endpoint requires an unpredictable token or a checked Origin header, the forged request is rejected even though the session itself is valid.

Which Actions Are Most at Risk from CSRF?

Endpoints that change server-side state are the real targets. Typical examples include:

• Email, password, and recovery setting changes
• Permission or role grants, including adding administrators
• Fund transfers and changes to transaction destinations
• API key creation, account linking, and integration setup

Read-only pages offer an attacker little, because a forged request’s response cannot be read across origins.

How Does the Victim’s Browser Send the Forged Request with Their Session Cookie?

Browsers attach the cookies stored for a domain to every request sent to that domain, regardless of which page triggered the request. When a victim loads attacker-controlled content, a hidden form or automatically loaded resource can send a request to the target application, and the victim’s session cookie travels with it. The server then treats the forged request as an ordinary action by an authenticated user.

Can a CSRF Attack Read the Victim’s Data?

Classic CSRF is a blind attack: the same-origin policy prevents the attacker’s site from reading the cross-origin response, so the attacker knows only that a request was sent. That is why CSRF is aimed at state-changing actions rather than data theft. Reading responses generally requires a separate weakness, such as XSS or an overly permissive cross-origin configuration.

How Can Teams Detect CSRF Activity?

Watch for high-impact state changes that affected users did not initiate, requests to sensitive endpoints arriving with external Origin or Referer values, and short bursts of actions that follow navigation from an outside site. Logs should record the session, endpoint, prior state, and resulting change so investigators can reconstruct what happened and identify every affected account.

What Should You Do After a Suspected CSRF Incident?

Review the affected session’s activity, revert unauthorized changes to email addresses, permissions, or recovery settings, and revoke any API keys, tokens, or accounts the attacker created. Force reauthentication for impacted sessions and identify which endpoint accepted the forged request so its validation can be repaired before the account is used again. Note that changing a password alone may not terminate an attacker’s existing session on every platform, so confirm how your session controls behave.

How Do Anti-CSRF Tokens Protect State-Changing Requests?

A synchronizer token is an unpredictable value issued with the page and bound to the user’s session. The server accepts a state-changing request only when it carries a matching token, which a form on another site cannot know or set. Tokens belong in the request body or a custom header and never in URLs, where Referer headers, logs, and browser history can leak them.

Do SameSite Cookies Make CSRF Tokens Unnecessary?

SameSite attributes limit when cookies accompany cross-site requests, and modern browser defaults already block many classic attack paths. The protection depends on the attribute mode, the browser, and the navigation type, and some legitimate flows still send cookies across sites. Treat SameSite as one layer that reduces exposure, and keep token checks or Origin validation on every state-changing endpoint.

Why Should State-Changing Actions Avoid GET Requests?

Browsers and intermediaries issue GET requests on their own: prefetching, link previews, crawlers, caches, and embedded resource tags all fetch URLs without the user intending an action. If a GET URL triggers a transfer or a permission change, a single fetched link can perform it. Keeping GET safe and idempotent and reserving changes for POST with token validation closes that gap.

Are JSON APIs and Mobile Endpoints Automatically Safe from CSRF?

Not automatically. An endpoint stays exposed whenever a browser attaches a session cookie and the server accepts the request without token or Origin checks. APIs that require a custom authorization header set by trusted client code sit largely outside classic HTML-form CSRF, because browsers only send such headers after a successful CORS preflight that an attacker’s page cannot obtain, and native mobile apps that do not rely on ambient browser cookies are generally outside this attack model.

How Can Organizations Find Endpoints That Lack CSRF Protections?

Inventory every web application and its state-changing endpoints, including legacy and rarely touched systems, then test each action for token validation, Origin checks, and safe method use. Code review and penetration tests typically surface these gaps, and teams with large estates often pair that testing with attack surface discovery, such as the exposure mapping SOCRadar provides, so forgotten internet-facing applications do not escape testing.

What Is the Difference Between CSRF and Cross-Site Scripting (XSS)?

CSRF makes the victim’s browser send a request the user never intended, while XSS executes attacker-controlled script inside the trusted application’s pages. The two compound each other: script running on the target origin can read anti-CSRF tokens and submit valid requests directly. Addressing CSRF without addressing XSS leaves the same actions reachable, so both weaknesses need attention.