エンドポイントとして用意する。試みられることを前提に考える。この脆弱性が生まれる原因は主に次の2点からなる。指定することができる。リクエストに自動的に付与される。情報を確認したのちにリクエストの正当性を検証することが多い。付与された状態でリクエストが渡ってくるため、サーバサイドとしては自サイトからリクエストが発行された時と同様に処理を行ってしまうことで、ユーザ本人にとっては意図しない副作用が実行されてしまう。自サイトからのリクエストであることを確認する。正規利用者の意図したリクエストであることを確認する。付与しないようにする。どのサイト上から発行されたリクエストなのかを確認し、自サイト上で発生したものでなければ処理を行わないようにする。この方法には考慮しなければならない点がある。情報を送信しないように設定することができる。付与されていないため、サービス利用が事実上不可能になってしまう。以外の情報も組み合わせて正当性を検証することで対策をするものである。頼っているためである。その1つは、パスワードの再入力を要求することである。重要な処理を実行する画面では、あわせてユーザのパスワード入力も要求し、リクエストにはそのパスワードも含めて送信する。サーバサイドではパスワードの正当性を検証し、問題がなければ処理を進める。試みた場合、ユーザのパスワードをリクエストに含めなければいけないが、それがわからないため攻撃は成立しなくなる。観点から検討が必要である。トークンを扱う方法である。トークンと同じものが送られてきていることが確認できれば、ユーザが自サイト上で発行した正当なリクエストであることが確認できる。トークンを発行しておき、クライアント側ではメモリ上にトークンを保管、以降リクエスト時にそれを付与するといった方法もとられる。フィールドを設けて、そこにトークンを設定してリクエストを発行する形を取ることが多い。詳細は以下を参照のこと。対策として策定されたもので比較的新しい仕様である。