Web アプリケーションには「さまざまな場所から呼び出されることを想定しているもの」と「特定の場所からのみのアクセスを想定しているもの」の 2 種類が存在する。例えば、サーチエンジンの検索フォームなどは前者であり、パスワード変更フォームなどは後者である。

特定の場所から呼び出されることを想定しているのであれば、その呼び出し元をコントロールする責任は Web アプリケーション側にある... と言うよりも、そのようにするのが自然な発想であろう（これは、高木氏の「サニタイズ言うなキャンペーン」における「（外部から入力された任意の）値」と「（出力に応じた適切な）エスケープ」の関係に似ている）。これを行わないのは開発者の怠慢であり、その結果が CSRF 脆弱性となる。

さまざまな場所から呼び出されることを想定している Web アプリケーションを除いても、サイトを跨いで（acceptable な）リクエストを送信することのできる Web アプリケーションはどこにでも存在する。例えばこの blog のコメントフォームでは「記事ページからのアクセスを想定している」にも関わらず、ワンタイムトークンや Captcha といった技術を使用していないため、クロスサイトでコメントを投稿することは可能である。私がそのような状態でコメントフォームを運用しているのは、（その作業時間が実情にペイしないという理由もあるが）このシステムが CSRF 脆弱性を持つとは認識していないからである（本来的に「脆弱性」とは第三者のユーザに対して被害がある場合に生じるもので、Web アプリケーションの運営者のみが被害を蒙る場合を含まない、という考えに基づく）。

　＊

なぜこのようなことを書くのかと言うと、このような記事を読んだからだ。記事長の制限もあろうが、CSRF 対策について書いた記事としては内容がいい加減過ぎる。

例えばパスワード変更の処理要求を受け付けた後に確認画面を設ける方法。ユーザーが確認ボタンを押さなければパスワードは変更されない。

本人は分かって書いているのだろうが、これでは対策として不十分（確認フォームの次の画面に対して CSRF を仕掛けられる）。また、ユーザの対策として

（1）スパム・メールに記載されているリンクや掲示板に記載される不審なリンクなど，信頼のおけないリンクを不用意にクリックしないように日常から意識する
（2）ブラウザが記憶するクッキーなどのデータを可能な限り無効化する
といった基本の順守しかない。

と書いているが、(1) 信頼できないリンクをクリックしないだけでは攻撃は防げない（例えば、Web メールで HTML 形式のメールを開くと、メール中の img 要素によって自動的にリクエストが発生する場合がある。また、信頼している Web サイトに XSS 脆弱性などが存在する場合は、その Web サイトを開いただけで攻撃を受ける可能性がある）。(2) に至っては、ユーザにとっての「基本」でさえないだろう。貴方は本当に Cookie を無効にして Web を使っているのか？と問いたい。しかも「など」とは何を指すのか？意味不明。
正しい（ユーザ側の）対策としては、

(1) Web サイトの「次回からログインを省略」機能を使わない
(2) Web サイトを使い終えたら直ぐにログアウトし、ログアウト前は他の Web サイトに移動しない（特にインターネットバンキングなど、重要なサービスを利用している間）

等が挙げられよう。