Webアプリの主要セキュリティリスク一覧で触れた「CSRF・CORSの設定ミス」を掘り下げます。名前が似ていて紛らわしいので、まず違いから整理します。
| 略語 | 正式名 | 何の話か |
|---|---|---|
| CSRF | Cross-Site Request Forgery | ログイン中のユーザーに、意図しない操作を実行させる攻撃 |
| CORS | Cross-Origin Resource Sharing | どのサイトからのアクセスを許可するかを決める、ブラウザ側の仕組み |
CSRFは「攻撃の名前」、CORSは「防御にも設定ミスにもなり得る仕組みの名前」です。
CSRF：ログイン中に、別サイトを開いただけで
あるサイトに、送金や設定変更のようなフォームがあるとします。ログイン中のユーザーが、まったく別の、攻撃者の用意したページを開くと、そのページに仕込まれた仕掛けが、ログイン中のサイトへ向けて勝手にリクエストを送信します。ブラウザは自動的にログイン用のCookieを一緒に送るので、サーバー側からは本人が操作したリクエストと区別がつきません。
「別サイトを開いただけ」で被害に遭う、というのがCSRFの怖さです。攻撃者は、リンクを踏ませるか、仕込んだページを表示させるだけで済みます。
対策の具体策
- CSRFトークンを使う。 フォームを表示するたびに、その場限りのランダムな値（トークン）を埋め込み、送信時にその値が一致するかを確認する仕組みです。攻撃者は事前にこの値を知ることができないので、なりすましの送信を弾けます
- Cookieに
SameSite属性を設定する。 この属性は、「別のサイトからのリクエストに、このCookieを付けて送ってよいか」を制御します。StrictやLaxに設定しておくと、別サイト経由のリクエストにはログイン用のCookieが自動では付かなくなり、CSRFの土台そのものを弱められます - 多くのフレームワークは、これらの対策を標準で備えています。 まず確認したいのは、その標準の防御を、意図せず無効化していないかという点です
CORS：どこからのアクセスを許可するか
ブラウザには、あるサイトのJavaScriptから、別のサイトのAPIへ直接アクセスすることを、原則として制限する仕組みが備わっています。これがないと、悪意のあるサイトが、ログイン中の別サイトのAPIへ裏で自由にアクセスできてしまうためです。
自分のAPIを、別のドメインにある自分のフロントエンドから呼びたい、という正当な理由でこの制限を緩めるのがCORSの設定です。「このオリジン（サイトの発信元）からのアクセスは許可する」というリストをサーバー側で明示します。
典型的な設定ミス
「動かないから」という理由で、許可するオリジンを*（すべて許可）に設定してしまうケースがよくあります。これで動作確認上のエラーは消えますが、世界中のどのサイトからでも、あなたのAPIへ直接アクセスできる状態になります。
とくに危険なのが、Cookieを使った認証と、緩すぎるCORS設定を組み合わせたときです。この組み合わせでは、任意のサイトが、ログイン中のユーザーの権限でAPIを呼び出せてしまう可能性があります。
対策の具体策
- 許可するオリジンは、必要なものだけを明示的に指定する。
*は「困ったから全部許可」であって、対策ではありません - Cookieを使った認証と組み合わせる場合は、とくに慎重に設定する。 許可するオリジンを絞ったうえで、必要な場合のみCookieを含むリクエストを許可する設定にする
エージェントへの頼み方
「フォームの送信処理に、CSRF対策（トークンの検証やSameSite属性）が働いているか確認して」「APIのCORS設定を確認して、許可しているオリジンが*のような広すぎる設定になっていないか教えて」のように、それぞれ具体的に頼むと点検が進みます。
まとめ
- CSRFは、ログイン中のユーザーに別サイト経由で意図しない操作をさせる攻撃。対策はCSRFトークンと
SameSiteCookie属性 - CORSは、どのサイトからのアクセスを許可するかを決める仕組み。「動かないから」で
*にしてしまうのが典型的な設定ミス - 名前は似ているが、CSRFは攻撃、CORSは設定という別の話。混同せずに、それぞれ個別に確認する
「動かないエラーを消すために設定を緩める」という判断は、あとから見直すことを前提にしておくと安全です。