Why do CSRF attacks still work when the application itself is legitimate?

CSRF succeeds because the browser and the user session are legitimate, even when the request is not. Attackers exploit trust in familiar sites, automatic credential handling, and unsafe state changing endpoints. If an application accepts forged requests for sensitive actions, the server cannot distinguish a malicious submission from a real one without additional request validation.

Why the browser’s trust model is the real problem

CSRF works because modern web sessions are designed to make the browser act on behalf of a logged-in user. When the browser automatically attaches cookies or other session material, the server sees a valid authenticated context even if the action was triggered from an attacker-controlled page. The weakness is not the application’s legitimacy, but its reliance on ambient browser trust for state-changing requests.

That trust model is why CSRF is different from a simple forged request against an unauthenticated endpoint. The attacker is not trying to prove they own the account, they are trying to cause the victim’s browser to speak with the victim’s authority. If the application does not require an additional proof that the request originated intentionally from its own interface, the server will accept the action.

• Legitimate session state can be present even when user intent is absent.
• Automatic cookie handling turns cross-site requests into authenticated submissions.
• State-changing endpoints are the main exposure, especially when they rely on session presence alone.

What makes a request distinguishable from a forged one

CSRF defenses exist to give the server a second signal beyond “this browser has a valid session.” That signal may be a synchroniser token, a double-submit token pattern, origin or referer validation, or a combination of controls that confirm the request came from a page the application itself rendered. Without that extra check, the server cannot reliably tell a deliberate action from a cross-site submission.

Controls matter most on endpoints that change state, trigger money movement, update contact details, alter security settings, or create new trust relationships. Safe methods and simple UI warnings are not enough if the backend still accepts the action without validating intent. In practice, the failure is often endpoint-specific: one forgotten form, API route, or legacy handler can keep CSRF alive even when the rest of the application is better protected.

• Validate request origin where the browser supplies trustworthy signals.
• Require per-request anti-CSRF tokens for sensitive state changes.
• Review every state-changing endpoint, not only the visible forms.

Why mature applications still miss CSRF

CSRF often survives because teams assume authentication is the same as authorization of the action. It is not. A logged-in session proves continuity of access, but it does not prove the current request was intentionally initiated by the user. This gap is easy to overlook in single-page apps, mixed browser and API architectures, and systems that gradually accrete older endpoints with inconsistent protections.

It also persists when developers rely on same-site expectations without testing real browser behavior. Modern cookie attributes help, but they do not replace application-level request validation for every sensitive path. For broader implementation guidance, the OWASP Web Security Testing Guide and the OWASP ASVS both treat request integrity, session handling, and access control as verifiable application security requirements. The practical lesson is that CSRF is usually a coverage problem, not a headline design flaw.

Risk and Threat Considerations

CSRF becomes material when the application exposes any action that changes account state, spending, permissions, recovery settings, or linked destinations. The threat is not just nuisance actions, it is unintended transfer of authority through a trusted browser session, which can lead to fraud, account lockout, or privilege changes without the victim noticing immediately.

Failure mechanism: The attacker relies on a victim’s authenticated browser automatically attaching valid session material to a cross-site request, while the server lacks a separate proof of request origin or user intent.

Impact: Sensitive actions may execute as if they were user-approved, creating unauthorized changes that are hard to distinguish from legitimate activity after the fact.

Practitioner Guidance

What to verify: Treat every state-changing endpoint as suspect until you confirm it rejects cross-site submissions without an application-generated token or equivalent intent check. Verify the protection on password changes, email updates, payment actions, admin toggles, and any route reached outside the main UI flow.

Common mistake: Do not assume modern browser cookie defaults make CSRF go away. They reduce some exposure, but they do not protect legacy handlers, custom integrations, or endpoints that still accept authenticated requests without validating where the request came from.

Practitioner takeaway: CSRF persists wherever the server trusts “authenticated session present” as enough proof of intent, so the real control objective is request authenticity, not just user login.

Related resources from NHI Mgmt Group

• Why do adversary-in-the-middle attacks still work when MFA is enabled?
• Why do MFA fatigue attacks still work in mature IAM programmes?
• Why do MFA fatigue attacks still work when MFA is already deployed?
• Why do credential stuffing attacks still work when 2FA is enabled?