Cross-Site Request Forgery (CSRF) Attack

How CSRF Works in Practice

CSRF is dangerous because the browser supplies the victim’s ambient authentication automatically, so the server sees a request that appears to come from an already trusted session. The attack is not about breaking cryptography; it is about abusing trust in the browser-to-site relationship and the application’s assumption that “authenticated” means “intended.”

A CSRF attempt usually succeeds only when the targeted action changes state and the application does not require a stronger proof of user intent. That is why high-value actions such as password changes, email changes, payments, permissions edits, or profile updates deserve stronger anti-automation checks than ordinary read-only pages.

Why CSRF Is a Web Application Security Problem

CSRF sits in the same family as other request-integrity failures in web applications, but its trigger is different: the user is not tricked into revealing a secret, they are tricked into causing a browser to reuse one. This makes the weakness especially relevant wherever a session cookie or similar ambient credential can authenticate browser requests across tabs, sites, or embedded content.

Defences work by making the forged request distinguishable from a legitimate one. Anti-CSRF tokens bind the request to application state, SameSite cookie settings reduce cross-site cookie attachment, and origin or Fetch Metadata checks help the server recognise when a request arrived from an untrusted browsing context. The strongest protection is usually layered rather than singular, because browser behaviour and application frameworks vary.

For teams that need implementation detail, NHIMG’s CSRF Prevention Guide covers synchroniser tokens, signed double-submit patterns, Fetch Metadata, SameSite cookies and the framework settings worth auditing.

How Organisations Assess Exposure and Reduce Blast Radius

Exposure is highest where a site still relies on cookie-authenticated state changes and accepts requests without checking whether the request was intentionally initiated inside the application. Older browser assumptions, inconsistent framework defaults, and mixed use of same-site and cross-site flows can all leave gaps, especially in admin portals and customer account areas.

Organisations should review which endpoints actually change state, which are reachable cross-origin, and whether their framework enforces CSRF checks by default for every unsafe method. The practical question is not whether a site “has CSRF enabled,” but whether every meaningful state-changing path is protected consistently, including API-adjacent browser flows and less obvious actions such as preference updates or transaction approvals.

For broader context on web attack classes that often overlap in remediation work, see NHIMG’s Web Application Attacks Guide, which places CSRF alongside other request-manipulation patterns defenders need to recognise.

Detection, Testing, and Post-Compromise Review

CSRF is often quiet at runtime because the malicious request can look structurally valid. Detection therefore leans on behaviour, such as unexpected state changes, unusual referrers or origins, missing anti-CSRF tokens, or repeated requests that come from pages that should never be able to trigger the action.

After a suspected CSRF incident, the review should focus on what state could have changed without user intent, whether the forged action created follow-on access, and whether the application later relied on those changed settings for persistence or privilege. If the action altered account recovery details, email addresses, or admin settings, the compromise review may need to treat the session and any downstream trust decisions as tainted.

When a site uses browser-side isolation signals, NHIMG’s Fetch Metadata and Resource Isolation Policy Guide explains how request headers can help reject cross-site traffic before it reaches sensitive logic.

Risk and Threat Considerations

CSRF matters because it turns the victim’s authenticated browser into an unwilling action source. The practical risk is unauthorized state change, not login theft, and the business impact can range from nuisance account changes to durable privilege, payment, or access-control abuse.

Failure mechanism: The application trusts an ambient browser credential without separately verifying user intent, so a cross-site request reaches a state-changing endpoint and is accepted as legitimate.

Impact: Attackers can alter account data, approve unwanted actions, weaken security settings, or pivot into higher-impact abuse if the forged change creates new access paths or trust relationships.

Practitioner Guidance

What to watch for: Treat every state-changing browser endpoint as unsafe unless it has an explicit anti-CSRF control path. The most common mistake is protecting the login flow or a few obvious forms while leaving account management, settings, and admin actions exposed through framework defaults or legacy endpoints.

Practitioner takeaway: CSRF control is strongest when the application verifies intent at the request boundary and does not rely on cookies alone to prove that a user meant to perform the action.

Related resources from NHI Mgmt Group

• Cross-Site Request Forgery
• Request Forgery
• Forgery Attack
• Forgery