攻撃者の入力はどこまで届く？WebとAIの権限境界を検証する

攻撃者が得られる権限から考える

説明用に、非公開文書を保存し、外部providerを呼び、AIが回答を下書きするサービスを考えます。匿名の利用者、他人の文書を要求する正規ユーザー、不正な応答を返すprovider、改変された文書は、それぞれ異なる入口です。packageの監査だけでは、この4つを止められると判断できません。

routeごとに、攻撃者が制御する入力と、狙う結果を書きます。文書の読み取り、データ変更、秘密の送信、tool実行、課金枠の消費などです。その間の実装をたどり、小さな再現テストへ落とします。以下の演習はローカルmockと合成データを使う設計例です。本記事のために本番サービスへ攻撃を行っていません。

本人確認と、その文書を操作できる権限を分ける

認証は「誰か」を確認し、認可は「その主体が、そのresourceに、その操作をしてよいか」を判断します。読み取り、書き込み、非公開データを使う外部通信の前で、両方を検査します。

たとえばユーザーAがログインできても、recordId=B-recordを読む権限は得られません。検証済みsessionから主体を解決し、その主体に許可された範囲で文書を取得してから操作します。ボタンの非表示、推測しにくいID、clientが送るowner値は認可の代わりになりません。OWASPの認可ガイドも、既定で拒否し、requestごとに権限を検証する方針を示しています。

Workerの前にAccessを置く場合も、originでAccess JWTを検証します。期待する鍵の取得先で署名を検証し、issuer、対象アプリのaudience、有効期限などの時刻条件を確かめます。email headerがあるだけでは本人確認になりません。別routeや直接originからの入口も確認します。CloudflareのJWT検証手順がorigin側の契約を説明しています。

cookie認証で状態を変える処理には、そのアプリのCSRF対策も必要です。CORSだけでは別clientからの送信を止められず、resourceのownerも確認できません。実際に副作用を起こすserver側の経路で検査します。

許可したURLから、別の宛先へ権限が移る

SSRFは、攻撃者がserverの通信位置やcredentialを使い、意図しないrequestを送らせる問題です。外部providerが1つでよければ、provider用IDを受け取り、server側で宛先を組み立てます。柔軟性のためだけに任意URLを受ける入口を増やさないようにします。任意の外部サイトへ通信する製品では、DNSやprivate networkを含む、より広いegress設計が要ります。OWASPはこの2つの用途を分けて説明しています。

Cloudflare Workersではredirectの仕様にも注意が必要です。新しく作るRequestの既定はfollowで、redirect先のhostが変わってもAuthorizationやCookieを含むheaderを転送します。受信したclient Requestの既定はmanualです。redirect: "error"はWorkersでは未実装で、Request生成時に例外になります。manualでredirectを拒否するか、許可する移動先を毎回検証し、headerを組み直します。これはWorkersのRequest仕様に基づく挙動であり、browserの挙動から類推しないようにします。

redirectが不要な認証付きprovider呼び出しでは、次の順で処理します。

sessionと文書の所有権を検証
serverが保持するprovider originと検証済みIDからHTTPS URLを生成
providerへの呼び出しに必要なheaderだけを作成
manual redirectと全体の期限を付けてfetch
3xxなら次のrequestを送らず拒否し、bodyの読み取りも中止・破棄
設定したbyte数まで応答を読み取り
期待する応答構造を検証
upstreamの秘密や生のエラーを含めずアプリの結果を返す

これは設計上の順序であり、完成した実装ではありません。ローカル試験では、2つ目のmock originへredirectする応答を作ります。そのoriginへのrequestが0件で、応答にもprovider tokenが含まれないことを確認します。最後のHTTP statusだけでは、エラーを返す前に秘密を送ってしまった問題を見逃します。

parseの前と途中で、仕事量を制限する

操作に応じてrequest byte数、field数、文字列長、対応するparserなら深さ、response byte数、同時実行数、経過時間を制限します。byte上限だけで、すべての高負荷なparseを制限できるわけではありません。ソースコードの型も、通信で届く入力を検証しません。

stream応答は受信したbyte数を数えます。Content-Lengthは存在しなかったり、不正確だったりします。上限や期限で読み取りを止め、upstreamの処理を中止します。拒否したredirectやHTTP errorのbodyも中止・破棄し、失敗経路にstreamを残さないようにします。失敗時にupstream bodyをそのまま返さず、安定したアプリ用errorとrequest IDを返します。OWASPのRESTガイドは、入力上限、media type、内部エラー情報を漏らさない扱いを説明しています。

具体的な要件から数値を決め、境界とその直外を試します。たとえば小さなmetadata取得を「応答64 KiBまで、全体5秒まで」と設計したなら、正常な小応答、64 KiBを超えるstream、終わらないstreamを試します。この数値は説明用の設計値であり、普遍的な既定値や本番で測った値ではありません。

非公開データを共有cacheへ混ぜない

cacheやmemo化もデータの流れとして確認します。cache keyにユーザーやtenantが入っていないために、認証済みの応答が匿名へ返ってはいけません。privateな文書を共有する必要がなければ、そこでの共有再利用を避けます。必要なら、許可された範囲を設計に含め、2主体で検証します。

Aの合成文書で対象経路をwarmにした後、Bと匿名で同じrouteを要求します。errorやredirect経路も含め、Aに固有のmarkerが応答へ出ないことを検査します。最初のrequestでcache missだったことだけでは、warmなprocessや再requestの挙動を確認できません。

基盤の隔離とアプリの認可も、別の責任です。2026年9月24日のContainers報告でCloudflareは、storageの残存データ露出とfleet側の修正を説明しています。利用者の設定変更は不要で、利用可能なtelemetryには悪用の証拠がなかったとしています。過去の報告から現在のアプリに同じ欠陥があるとは言えず、基盤の修正からアプリのowner検査が正しいとも言えません。

モデルの出力は、操作案として扱う

外部文書がAIに新しい送信先を指定したり、管理者承認済みだと主張したりしても、それは内容であって権限ではありません。tool、引数、宛先、resource owner、現在のユーザー許可を、モデルの外で検証してから実行します。

OpenAIの2026年3月11日の分析は、非信頼入力から危険な能力へつながる経路をsource–sinkとして扱っています。自作アプリでは「モデルが誘導に従った」と仮定した試験が役立ちます。それでも実行層が未許可の操作を拒否できるかを確かめます。promptや入力分類だけでは、その境界を証明できません。

費用も副作用として扱います。tool回数、retry回数、入力・出力サイズ、並列数、総経過時間を実行層で制限し、requestがどの利用枠を消費するかを特定します。browserの切断後に無制限の生成を残さないようにします。upstreamのtimeoutで書き込み結果が不明なら、再試行前に結果を照合します。エラー表示は、書き込みが起きなかった証拠にはなりません。

小さな攻撃者視点の回帰試験を作る

異なる合成ユーザーとmock宛先を使います。応答だけでなく、観測できる副作用も検査します。

試験条件	必要な観測
Aが許可されたAの文書を要求	期待する結果と、認可済みの読み取り1回
BがAの文書を要求	拒否し、非公開の結果も特権付き外部通信もない
匿名で別origin・別routeへ要求	private処理の前で拒否
providerが別のmock originへredirect	そのoriginへのrequestもcredential転送もない
応答streamが上限・期限を超える	読み取りを止め、処理を中止
Aがcacheをwarmにした後、Bが要求	AのmarkerをBへ返さない
モデルが未許可の宛先・toolを提案	実行層が拒否し、副作用0件
timeout後、clientが副作用付きrequestを再送	許可した副作用は最大1回、最終状態が明示される

AIによるコード監査には、次の指示を使えます。

攻撃者が制御する入力から、非公開の読み取り、書き込み、外部通信、tool実行、課金処理まで追ってください。server側の制御箇所と、それが欠けたときの具体的な検査を示してください。ローカルmockと合成ユーザーを使い、再現した失敗を修正し、正常系を保ってください。コード検証、配信検証、未検証の仮定を分けて報告してください。

ローカル試験の合格が示すのは、そこで通した経路とruntimeの範囲です。通常の配信手順で反映した後、変更したrouteと認可境界を確認します。logにはrequest ID、判断、上限、停止理由を残し、credentialや非公開の全文を含めないようにします。