Cross-Site Request Forgery

Cross-site request forgery is a web-application flaw that tricks a user's authenticated browser into sending an unintended request.

Cross-site request forgery, or CSRF, is a vulnerability that causes a user’s browser to send an unintended request while the user is already authenticated to a target application. In plain language, the application mistakes a browser request for a legitimate user action when it did not actually come from the intended workflow.

Why It Matters

CSRF matters because web applications often trust a user’s existing authenticated session. If the application does not properly verify that a sensitive request genuinely came from the expected interaction, an attacker may be able to trigger actions through the user’s browser state.

It also matters because CSRF highlights that authentication alone is not enough. A user can be genuinely logged in, but the application still needs safeguards around how state-changing requests are accepted.

Where It Appears in Real Systems or Security Workflow

CSRF appears in web applications with browser-based sessions, account settings, administrative consoles, and workflows that change data or permissions. Teams assess it during secure coding review, DAST, and application testing focused on how authenticated requests are protected.

Security teams often review CSRF alongside session management, Authorization, and sensitive action workflows because those controls need to work together.

Practical Example

A user is already signed in to a web-based admin console in one browser tab. If the application accepts sensitive requests without verifying that they came from the expected trusted workflow, another site or crafted action may be able to cause the browser to send a request the user never intended.

Common Misunderstandings and Close Contrasts

CSRF is not the same as Cross-Site Scripting. CSRF abuses an existing authenticated browser relationship to trigger unintended actions. XSS involves unsafe content execution in the browser.

It is also different from SQL Injection, which targets database query handling rather than browser-authenticated request trust.