制作裏話

Vibe Coding時代の「AI脆弱性」対策｜HttpOnlyの限界を超える多層防御セキュリティ

  • Published

読了の目安: 約 12 分

Vibe Coding時代の「AI脆弱性」対策｜HttpOnlyの限界を超える多層防御セキュリティ

AIツールにプロンプトを与え、対話形式で爆速でコードを生成・修正させる「 Vibe Coding（バイブコーディング） 」が新しい開発スタイルとして定着しつつあります。

仕様通りに 動くからヨシ って思ってませんか？ コードの背後にあるセキュリティリスクまで、私たちは くまなく検証できている でしょうか？

Webフロントエンドの本質は、ユーザーのブラウザという「完全にオープンな環境（敵陣）」でコードが実行される点にあります。

具体的には、「LocalStorageへのJWT保存（トークンの保存）は危険だから、cookie httponly を使えば100%安全」と言われてきました。ところが、現在の加速する脅威の前では、その言説は半分正解で半分間違いであると言わざるを得ません。

本稿では、最新のAI脆弱性の傾向を踏まえ、ログイン状態を証明する通行証（ ※以後トークン ）を単に「漏らさない」だけでなく、万が一の状況でも「悪用させない」ための、「 多層防御セキュリティ 」戦略について考えていこうと思います。

【ベース知識】フロントエンドにおける「信頼境界」の整理

インフラセキュリティの「入口・内部・出口」の概念は、ブラウザ環境でも同じです。まずは、フロントエンドという非常にオープンな特性を整理しつつ、それぞれの領域で発生するリスクの本質について考察してみましょう。

ブラウザという「オープンな戦場」

Webサイトのソースコードや実行中のメモリ、ストレージ領域は、悪意あるユーザーや不正なブラウザ拡張機能から 常にアクセスできる状態 です。 特に恐ろしいのは、LocalStorage や SessionStorage に格納されたデータは、同一ドメイン上でJavaScriptが実行された場合、何の制限もなく読み取られてしまいます。

これは、サイト内に 1箇所でもXSS（クロスサイトスクリプティング）脆弱性が存在 していれば、保存した認証情報は即盗まれるということを示唆します。 これが、 LocalStorageにJWT（JSON Web Token）を保存してはならない とされる根本的な理由です。

Cookie属性「HttpOnly」の役割と限界

LocalStorage に代わるアプローチとして広く使われているのが、Cookieの HttpOnly 属性（フラグ）です。

Cookieに HttpOnly 属性を設定すると、ブラウザ上のJavaScriptからそのCookieへアクセスが技術的に遮断されます。

万が一WebサイトにXSS脆弱性があり、悪意あるスクリプトが注入・実行されたとしても、JavaScript経由で認証トークンを直接読み取られるリスクがなくなります。結果、セッション情報を盗んでアカウント不正乗っ取り（セッションハイジャック）を防御することができます。

残念ながら HttpOnly 属性は万能ではありません。
HttpOnly 属性はJavaScriptからの読み取りの制限はできても、ブラウザがリクエスト送信時にCookieを自動的に送る挙動自体は制限不能です。
トークンの「漏洩」は防げても、トークンを「悪用」した別手法の攻撃を許してしまうという限界があります。

// クッキーの中身（トークン）は読めないが、通信の命令は出せる
fetch('/api/v1/update-email', {
  method: 'POST',
  body: JSON.stringify({ email: 'attacker@example.com' }) // 犯人のメールアドレスに変える
});

※ XSSで注入されたスクリプトを介して、非同期通信でデータを不正操作・窃取されるリスクは残ります

トークン格納場所の最終結論：BFF（Backend For Frontend）構成

ブラウザ側にはトークンを一切保存せず、BFFサーバーが中継して安全な「httpOnly Cookie」でセッションを維持する仕組み。これにより、XSS（クロスサイトスクリプティング）によるトークン窃取を完全に防ぎます。

※Backend For Frontend：フロントエンド（ブラウザやスマホアプリ）専用に用意された、仲介役のサーバー

BFFを使ってユーザーが「マイページを開く」ときの動き

  • フロントエンド視点： 認証や複雑なデータ整形を丸投げできるので、楽で安全。
  • バックエンド（API）視点： 信頼できるBFFサーバーからのリクエストだけを相手にすればいいので安全。

【現代の脅威】Vibe Codingが量産する「AI脆弱性」の正体

AIツールの出力で「動くだけのコード」を量産する開発こそ、セキュリティの盲点と断言します。そこでここでは、AIがコンテキストを考慮せずに出力したコードの隙を突き、間接的な不正操作を狙う「AI脆弱性」の脅威についてお話します。

調査機関 / レポート調査項目主な統計データ / 推移
IBM X-ForceAIを悪用したサイバー攻撃前年比 72% 増加
Tech Advisors生成AIによるフィッシング攻撃前年比 1,265% 爆発的増加
Hoxhunt (2026)攻撃全体に占めるAI生成の割合1ヶ月間で 56%（約14倍）に急増
世界経済フォーラム (WEF 2026)AI関連を最大のリスクとする専門家全体の 87% が警鐘

「動けば正解」の落とし穴：AIコーディングが招くセキュリティの盲点

AIはアプリケーション全体のコンテキスト（文脈）や、システム全体の設計における安全性までを 自律的に考慮してコードを組み立てているわけではありません 。提示されたプロンプトに対して「要求された機能を満たす最短のコード」を即座に生成しているに過ぎないということ。

開発者が提示した部分的なテストケースさえパスすれば、AIにとっては 正解 です。結果、表面上は意図通りに動作しているように見えても、データの信頼境界（トラストバウンダリ）を考慮していない、重大な欠陥を抱えたコードがレビューをすり抜けます。一見動きますが、文字通り穴だらけのコードです。

フロントエンドで多発する「AI生成コード」の典型的な失敗パターン

Vibe Coding で、フロントエンド開発での具体的な危険なパターン大きく2つ。

  • エスケープ処理の不足によるXSSの埋め込み：
    AIは早くUIを構築しようとするあまり、セキュリティ上のリスクが高い関数やプロパティを採用する傾向があります。たとえば、Vue.jsの v-html や Reactの dangerouslySetInnerHTML、バニラJavaScriptの innerHTML を、適切なサニタイズ（無害化）処理を挟まないまま出力するロジックを生成します。外部からの入力値が悪意あるスクリプトとしてそのままブラウザで実行されてしまう、典型的なXSS脆弱性が埋め込まれます 。
  • セーフティフラグの省略（最小構成への依存）：
    AIは ローカル環境やテスト環境で意図通りに動くこと を優先したコードを書きがちです。そのため、認証リクエストやセッション管理の実装を依頼した際、Cookie発行に必要な SameSite や Secure 属性の設定、あるいは各種セキュリティヘッダーの付与を 動かすための最小限の構成 として省略してしまうケースが多発します。本番環境へのデプロイを考慮した厳格な設定フラグは明示的に指示しない限り抜け落ちやすく、CSRFなどの攻撃を許す直接的な原因となります。

脆弱性検出も自動化？AIによるセキュリティ対策は「両刃の剣」

通常、Claudeなどの一般的な商用AIには厳格な倫理フィルターがかけられており、攻撃コードの直接的な生成は拒否されます。

しかし、これで安全と言い切ることはできるのでしょうか？

昨今、ダークウェブをはじめとするブラックマーケットでは、倫理制限ゼロ、サイバー攻撃に特化させた独自の悪意あるAIツール（FraudGPTやDarkBERTの系譜など）がサブスクリプション形式で広く流通しています。しかも安価に。

通常の商用AIであっても、 コードのデバッグやセキュリティ監査（リバースエンジニアリング） という名目で、開発者を装ったプロンプト（二重用途プロンプト）を入力することで、実質的に脆弱性を炙り出せてしまう技術的限界もあります。

攻撃者側がAIを駆使して 防御の穴 を高速に探知できる環境が整っているからこそ、開発者が知識のないままAIコードを盲信するリスクは跳ね上がります。

【構造の深掘り】BFF構成でも防げない「漏らさない不正操作」

BFF（※Backend For Frontend）でトークンを隠蔽しても、ブラウザに自動送信の性質が残る限り 不正操作 は防げません。XSSで注入された悪意あるコードが、ユーザーのブラウザを踏み台にしてAPIを叩けるので、 トークン自体は一文字も外部に漏らさず にアカウントの乗っ取りや決済を完了だって可能です。

HttpOnly でJavaScriptからトークンを隠しても、これだけで対策が終わらない理由が CSRF（クロスサイトリクエストフォージェリ） です。

原因は、ブラウザの「親切すぎる仕様」にあります。ブラウザは「そのサイト宛ての通信には、保存されているCookieを自動的にすべてくっつけて送る」という特性を持っているからです。

  • ユーザー： 正規サイトにログイン中（ブラウザにCookieがある状態）。
  • 攻撃者： ユーザーを別の「罠サイト」へ誘導する。
  • 仕掛け： 罠サイトを開いた瞬間、裏で「正規サイト宛てにパスワード変更などを要求する通信」が勝手に走る。
  • ブラウザの暴走： 送信先が正規サイトなので、ブラウザは HttpOnly であろうとCookieを自動添付して送信してしまう。

届いた通信には 本物のCookie があるため、サーバー側は本人のリクエストだと信じて処理を実行してしまいます。

トークンを盗まずに乗っ取る、遠隔操作「プロキシ型XSS」の恐怖

AIコードの隙を突かれてXSS（スクリプト注入）が成立した場合、攻撃者はもうトークンを盗む必要がなくなります。ユーザーのブラウザをそのまま 踏み台（プロキシ） にして、内部から直接APIを叩けばいいからです。

  • トークンは「読めない」が「使える」 HttpOnly で鍵が隠されていても、ブラウザの内部から正規のAPIへ通信（fetch等）を送る分には、ブラウザが自動で鍵をくっつけて通信を成立できます。
  • 「漏らさず」にすべてを奪う
    攻撃者は外部から命令を送るだけで、ユーザーのブラウザに身代わりで「決済」や「パスワード変更」を実行できます。

データ自体は一文字も外部に 漏れていないのに、アカウントの権限だけが100%悪用 される。ログにも残らない、これこそが 現代Webの恐ろしい盲点 です。

【実践】「全く悪用させない」ための多層防御セキュリティ・ベストプラクティス

フロントエンドで、複数の防御層を設けることで、多様化するサイバー攻撃から情報資産を守る具体的な方法を解説します。

【入口対策】Cookieの SameSite 属性（Strict / Lax）の明示的制御

ブラウザのデフォルト挙動に依存せず、Cookie発行時に SameSite=Lax または Strict を忘れずに明示すること。罠サイトから送られる悪意あるクロスサイト通信へのCookie自動添付を遮断します。

【内部対策】BFFレイヤーでのカスタムヘッダーチェックとOrigin検証

<form> タグ等によるブラウザ自動の CSRFリクエスト を一律で弾きます。 BFFのMiddlewareで、フロントエンドからの通信に X-Requested-With などの独自ヘッダーや Origin が含まれているかを検証します。

【出口対策】信頼された型（Trusted Types）と CSP（Content Security Policy）設定

CSPで許可された安全なドメイン以外へのデータ送信を強制遮断し、同時にTrusted Typesで危険な文字列がそのままJavaScriptとして実行されるのを根本から防御します。

万が一コードに脆弱性が混入しても、ブラウザレベルで被害を食い止める最後の砦となります。

結論：銀の弾丸はない。「多層防御」こそがエンジニアの社会的責務

AIコーディングは開発スピードを飛躍的に向上させました。ですが、それを安全にコントロールするのは人間の設計（多層防御）に他なりません。

  • AIを制御する多層設計
    開発を加速させるAIだからこそ、セキュリティはコード単体ではなく、人間が設計する「多層防御」で担保する必要があります。
  • 「3つの壁」の掛け算
    「盗ませない（BFF）」＋「通信させない（SameSite）」＋「流出させない（CSP）」を組み合わせ、攻撃経路を徹底的に塞ぎます。
  • 仕組みによる自動防衛
    個人の注意に頼らず、アーキテクチャの段階で自動的に防御が働くシステムを構築することこそが、現代フロントエンドの正解です。

「 動くコード 」を量産できる時代だからこそ、セキュアに設計できるエンジニアの価値が高まっています。