ひとことで言うと
CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）とは、ユーザーが意図しないHTTPリクエストを悪意あるサイトから自動的に送らせる攻撃手法です。例えば、ログイン済みのユーザーが悪意あるページを開いた瞬間に、そのユーザーの認証情報を使って別サービスへの操作リクエストが送られます。
攻撃が成立するには「ログイン状態のセッション」が必要です。そのため、ログイン機能を持たない純粋な静的HTMLのプレビューURLには直接的なCSRFリスクはありません。ただし、フォームの送信先が外部の認証付きサービスのAPIである場合は別の話です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
AIが生成したHTMLにフォームが含まれ、その送信先が自社のWebアプリAPI（たとえば`https://app.example.com/api/submit`）に設定されている場合、そのAPIがCSRF対策を実装していなければ、悪意あるHTMLから自動送信が可能になります。共有したHTMLが第三者によって改ざんされるシナリオも考慮が必要です。
ギガサイト便のようなプレビューサービスでHTMLを共有する場合も、フォームのaction先が外部APIを指していれば閲覧者の操作でそのAPIが呼ばれます。プレビュー用途ではフォームのaction属性を無効化しておくことで、CSRF経路の一つを事前に塞ぐことができます。
よくある誤解
「CSRFトークンをHTMLに書けばCSRF対策になる」は半分正解です。CSRFトークンはサーバー側が発行し、リクエスト受信時に照合して初めて有効です。HTMLにトークンを書いただけではサーバー側に照合ロジックがなければ意味がなく、静的HTMLでは本質的なCSRF対策はサーバー側の実装に依存します。
「HTTPSを使えばCSRFは防げる」も誤りです。HTTPSは通信の盗聴や改ざんを防ぎますが、正規のユーザーのブラウザから正規のリクエストを偽装する攻撃（CSRF）の仕組みとは別の話です。CSRFはHTTPS環境でも発生します。
安全に使うための注意点
フォームを含むHTMLをプレビュー共有する場合の最低限の対策として、action属性を無効URL（`action="#"`）に変更するか、JavaScriptで送信イベントを`preventDefault()`でキャンセルしてから共有してください。これによりプレビュー操作が外部APIを呼び出すリスクをなくせます。
フォーム送信先のAPIを自社で管理している場合は、APIにSameSite=Strict設定のCookieを使用するか、OriginヘッダーをチェックするCSRF対策をサーバー側に実装することを開発チームに確認してください。静的HTMLの共有はこのサーバー側対策が整っていることを前提として行うべきです。
よくある質問
ログイン機能のない静的HTMLプレビューでも、CSRFを心配する必要はありますか？
フォームのaction属性が認証付き外部APIを指していない限り、純粋な静的HTMLプレビュー（セッション不要）に直接的なCSRFリスクはほとんどありません。ただしaction先URLを確認し、外部サービスのAPIが設定されていないかを確認することは安全習慣として重要です。
CSRFトークンとnonce属性は同じものですか？
異なるものです。CSRFトークンはフォーム送信の正当性をサーバー側で照合するための値です。nonce属性はContent Security Policyでインラインスクリプトやスタイルを許可するための一時的なランダム値で、XSS対策に使われます。どちらもセキュリティ施策ですが目的が異なります。
AIが生成したHTMLのフォームにCSRF対策が含まれているか確認する方法はありますか？
HTMLソースでformタグ内にCSRFトークン用のhidden inputフィールド（例：`<input type="hidden" name="_token" value="...">`）があるか探してください。ただし静的HTMLではサーバー側の照合がないため、このトークンだけでは対策として不十分です。送信先APIの実装も合わせて確認が必要です。