「クロスサイトスクリプティング」とは異なります。

クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF（シーサーフ (sea-surf) と読まれる事もある[2][3]）、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。

なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の攻撃である。

CSRF脆弱性とは以下のような攻撃（CSRF攻撃）を可能にする脆弱性を指す[1]：攻撃者はブラウザなどのユーザ・クライアントを騙し、意図しないリクエスト（たとえばHTTPリクエスト）をWebサーバに送信させる。Webアプリケーションがユーザ・クライアントからのリクエストを十分検証しないで受け取るよう設計されている場合、このリクエストを正規のものとして扱ってしまい、被害が発生する。CSRF攻撃はURL[1]、画像の読み込み[1]、XMLHttpRequest[1]などを利用して実行される。

具体的被害としてはデータの漏えい[1]、意図しないコードの実行[1]、権限の取得[1]、なりすまし[1]、防御メカニズムの回避[1]、アプリケーションデータの読み取り[1]などがありうる。権限の取得が可能な場合、その被害はユーザの持つ権限に依存する。ログインしていない状態でも起こりうる主な被害としてユーザ・クライアントに電子掲示板などへ書き込みをさせる行為があり[6]、これを利用してユーザを装った犯罪予告（例：パソコン遠隔操作事件）や大量の書き込みをさせるDoS攻撃（例：「ぼくはまちちゃん」 騒動）といった事件が発生した。
詳細

CSRF脆弱性を具体例を用いて説明する。今ある銀行のWebサイト（標的サイト）にログインしているユーザALICEが自身の口座からBOBという別のユーザの口座に100ドルを送金する際、ALICEのブラウザからGET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

というHTTPリクエストが銀行のWebサイトに向かって送信されるものとする[注釈 1]。

攻撃者MARIAはhttp://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

というURLを公開掲示板に張ったり、不特定多数にメールしたりする[注釈 1]。

銀行のユーザALICEがこのURLをクリックしてしまうと、ALICEのブラウザからGET http://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

というHTTPリクエストが銀行に向かって送信される[注釈 1]。この際たまたまALICEが銀行にログインしていたら、銀行のサーバはこのリクエストを送金要求だと解釈してしまい、ALICEの口座からMARIAの口座に一万ドルが不正送金されてしまう。

本来、銀行のサーバは、ALICEのブラウザから受け取ったHTTPリクエストが本当にALICE当人の意志で送られたものなのかをチェックし、チェックを通った時のみHTTPリクエストを受け付けるべきである。

しかし上述した銀行サーバのWebサイトの実装にはこのようなチェック機構は備わっておらず、これがMARIAにCSRF攻撃を可能にしてしまった原因である。

上述の攻撃に対する対策の一例として、送金のHTTPリクエストにGET http://bank.com/transfer.do?token=13276598501&acct=BOB&amount=100 HTTP/1.1

のようにセッションIDとは別の送金用のtokenを含め、これが正しいtokenであるかを銀行サーバ側でチェックするというものがある（重要な注：説明を平易にする為この対策を記したが、この対策方法(他人に知られてはならない情報をURLへ含む方法？)はセッションハイジャックの危険という別の問題をはらんでいるので使用すべきではない[7][8]。よりよい対策方法は次章を参照）。

このようにすると、MARIAは（少なくとも前述の方法では）CSRF攻撃を行うことができない。tokenはALICEがログインするたびにランダムに決まるなど、MARIAがtokenを予想してURLを公開掲示板などに記載するのは困難な為である[注釈 2]。
偽装工作

CSRFの攻撃者は、攻撃用URLが銀行のものだとALICEに気づかれないようにするため、偽装工作をはかる事がある。例えば攻撃用URLを直接記載する代わりに<a href="（攻撃用URL）">面白い画像をみつけました</a>

と記載したり[注釈 3]、サイズ0x0の画像（のふりをした攻撃用URL）<img src="（攻撃用URL）" width="0" height="0" border="0">

を貼り付けたりする事で偽装できる[注釈 3]。なお、後者の偽装工作の場合、この画像が貼られたサイトにアクセスしてしまうと、ブラウザが自動的にこの「画像」を読み込んでしまうので、攻撃が成功する。
対策
利用者側

ログインしていることが必要な手続きにおいては、ログアウトをしてセッションを破棄しておけば認証確認の段階で手続きが拒否されるので被害が抑えられる。必要な手続きを済ませたならログアウトすることが望ましい。
Webサイト・Webアプリケーション製作者側

フォームを受け付けるWebサイト管理者（情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む）は、以下のような対策を施さなければならない。

よく知られた対策方法として、FormをHTTP GETする際に、十分な長さの暗号論的擬似乱数値（いわゆるnonce）をformのhidden値として発行し、HTTP POST時にサーバーに保存していた値とPOSTされてきた値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を推測することが困難なため、不正なPOSTはサーバ側で検出できる。（但し、HTTPヘッダ・インジェクション、セッションハイジャック、クロスサイトスクリプティングについても対策を施さなければ意味がない。