HttpOnly Cookieとは？HTML共有・AI生成サイトでの意味をやさしく解説

ひとことで言うと

HttpOnly属性はCookieに付けるフラグで、Set-CookieヘッダーにHttpOnly;と書くだけで有効になります。この属性が付いたCookieは`document.cookie`経由でJavaScriptから読み書きできなくなり、HTTPリクエストの際にのみサーバーへ自動送信されます。セッションIDや認証トークンをHttpOnly Cookieに格納しておけば、XSSでスクリプトを注入された場合でも値を外部に漏らされるリスクを大幅に下げられます。

HttpOnly属性はあくまでJavaScriptからのアクセスを防ぐだけで、ネットワーク上の盗聴は防げません。HTTPS通信と組み合わせて初めて十分な保護になります。AI生成HTMLのコードがCookieを扱う場合は、HttpOnlyとSecureの両属性がセットで付いているか確認する必要があります。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

HTML共有で関係する場面

AIで生成したHTMLにバックエンドAPIへのフェッチコードが含まれ、認証はCookieベースで行う設計の場合、HttpOnly属性付きのCookieを前提にしていると静的HTMLのみを共有しても認証が成立しません。認証部分をサーバー側で処理する構成は静的共有と相性が悪いため、プレビュー用にはモックデータや認証バイパスモードを別途用意しておくとスムーズです。

ギガサイト便のような静的HTML配信サービスはHTTPレスポンスヘッダーをHTMLから制御できないため、Set-CookieヘッダーでHttpOnly属性を付けることができません。Cookieを使いたい場合はJavaScriptからdocument.cookieを操作する形になり、必然的にHttpOnly保護が使えません。このような制約がある共有サービスでは、センシティブな情報をCookieに保存するコードは除去してから配信することを推奨します。

よくある誤解

「HttpOnly CookieはJavaScriptから完全に見えない」は正しいですが、「HttpOnly Cookieは絶対に安全」は誤りです。HTTPSを使わなければ通信経路で傍受される可能性があり、CSRF攻撃ではCookieの内容を知らなくてもリクエストを偽造できます。HttpOnlyはXSS経由の盗難には有効ですが、それ単独では万全ではありません。

「AI生成HTMLがCookieを読めないならHttpOnlyは関係ない」と思われることがありますが、AIが生成したHTMLに悪意あるサードパーティスクリプト（CDN経由）が含まれた場合、それらのスクリプトもdocument.cookieを読もうとします。HttpOnly属性が付いていれば読み取りを防げるため、共有前にCookieの設定方法を確認することには意味があります。

安全に使うための注意点

外部に共有するHTMLのコードにCookieを扱う記述がある場合、ブラウザ開発者ツールの「Application」→「Cookies」でHttpOnlyチェックが付いているかを確認します。HttpOnlyがついていないCookieにセッションIDが格納されている場合は、XSS脆弱性があれば即座に盗まれるリスクがあります。AIが生成したコードには属性が省略されやすいため、レビュー項目として明示的にチェックリストに加えておきましょう。

静的HTMLの共有ではサーバー側のCookie設定ができないため、認証情報はCookieではなくURLのクエリパラメータや署名付きトークンで扱うことを検討してください。ただしクエリパラメータはブラウザ履歴やサーバーログに残るリスクがあるため、機密度の高いプレビューにはパスワード付きURLやメール認証を提供するサービスを使うのが安全です。