Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) is an attack that tricks a browser into sending an unwanted request to a website. It often relies on the user's existing signed-in session. The site may accept the request as the user's own action, even though they did not choose to make that change. The attack is also called XSRF, sea surf, or session riding.

The target is a request that changes something, such as an email address or a password. The attacker does not see the reply, so the goal is the change itself.

Why a valid login is not enough

A browser may send a site's session cookie with a request automatically. That cookie helps the site recognize a signed-in user. It does not prove that the user intended the action. Extra checks help the site reject forged requests.

Authentication checks identity, while access control checks permissions. Both remain necessary, but neither stops CSRF, because a forged request carries the permissions of a real, signed-in account.

A healthcare example

Imagine a patient portal that lets a signed-in patient change their contact details. Without suitable CSRF protection, a link or page on another site could send that change on the patient's behalf. The attacker never needs the patient's password. The attack only needs the patient to be signed in.

This is an illustrative risk, not a claim about any particular portal. The safeguards belong in the app; a hosting BAA does not add them.

How apps reduce the risk

Use the framework's built-in protection, as OWASP advises, and confirm it covers every request that changes data. A common method uses a CSRF token: a secret, unpredictable value the server checks before accepting the action.

Never let a GET request change data. For high-risk actions, such as a password change, OWASP also suggests asking the user to sign in again.

Framework setup differs. Our CodeIgniter guide explains enabling its CSRF filter, which is off by default. Our Symfony guide notes that Symfony forms include tokens by default. Our CakePHP guide recommends session-based tokens, which are scoped to one user. Check the current docs for custom forms and other request paths.

SameSite cookie settings add another layer by limiting when cookies travel with requests from other sites. Set the attribute on session cookies yourself, because only some browsers apply Lax by default. OWASP calls SameSite useful defense in depth that does not replace a proper CSRF defense in most deployments. The same setting also blunts framed attacks, as our guide to clickjacking prevention explains.

HTTPS protects data in transit but does not by itself prevent CSRF. OWASP warns that cross-site scripting (XSS) can defeat every CSRF defense, so fix both. Short sessions help as well, because most forged requests need a live session. That is one more reason to set automatic logoff.

What HIPAA requires

HIPAA does not mention CSRF or CSRF tokens. It lets you choose any reasonable and appropriate measures to meet its standards (45 CFR § 164.306(b)(1)). Three parts of the Security Rule still apply.

The integrity standard at 45 CFR § 164.312(c)(1) requires policies and procedures to protect ePHI from improper alteration or destruction. A forged change to ePHI that the patient never meant to make is the kind of improper alteration this standard covers. The related mechanism at § 164.312(c)(2), to confirm that ePHI has not been altered or destroyed without authorization, is addressable.

The person or entity authentication standard at § 164.312(d) requires procedures to verify that a person or entity seeking access to ePHI is the one claimed. A forged request rides on a session that already passed that check, so sign-in alone does not stop CSRF.

Risk analysis and risk management at § 164.308(a)(1)(ii)(A) and (B) are both required. For an app that holds ePHI, record CSRF as a risk and note the control you chose.

Sources: OWASP CSRF Prevention Cheat Sheet; OWASP attack overview; MDN Set-Cookie and SameSite reference; Symfony documentation; CodeIgniter security documentation; CakePHP documentation; 45 CFR § 164.306, § 164.308, and § 164.312.