- Cloudflareは AnthropicのClaude LLM を活用して新しいOAuthライブラリを開発し、プロンプトも併せて公開した
- ライブラリのコード構造は整っているが、テストとセキュリティ検証 の面では多くの物足りなさがある
- CORSや一部の認証仕様の実装で、非標準的または危険な選択 が見つかった
- 暗号化実装には長所もあるが、重大なセキュリティバグ とプロトコルへの誤解が明らかになった
- LLMベースの自動コーディングは役立つものの、実務レベルのセキュリティ には専門家による綿密なレビューが不可欠である
Cloudflare OAuthライブラリの概要
- Cloudflareは OAuthプロバイダーライブラリ を、AnthropicのClaude LLMを活用して大部分を自動生成した
- Claudeの出力物は熟練したCloudflareエンジニアによる セキュリティおよび標準準拠のレビュー を受けており、コミット履歴ではAIとのやり取りの過程も透明に公開されている
- 初期実装後も、Claudeへの追加プロンプトと結果物のレビューを通じて品質を補強した
- AIのみに依存せず、RFC文書とのクロスチェック と中核的な専門家レビューが重視されていると明記されている
専門家の第一印象とコード分析
- LLMコーディング特有の傾向として コードが単一ファイル に集中しているが、構造は一貫しており、不要なコメントも比較的少ない
- 機能テストはあるものの、OAuthのような重要な認証サービスに求められる水準には達していない
- 必須（MUST/MUST NOT）仕様のチェックが欠けている箇所や、パラメータ妥当性検証の弱さが見て取れる
セキュリティ上の懸念と解説
1. CORSポリシーの問題 ("YOLO CORS")
- ほぼすべてのオリジンを許可し、同一生成元ポリシーが事実上解除 されるCORSヘッダー設定が見つかった
- これはCloudflareエンジニアがLLMではなく、人間が直接決定 した部分である
- credentials機能は有効化されておらず、致命的なブラウザセキュリティ脅威は小さいが、原因や目的の明確さに欠ける
2. 標準セキュリティヘッダーの未適用
- HTTPレスポンスに X-Content-Type-Options: nosniff や HTTP Strict Transport Security などの重要なセキュリティヘッダーが適用されていない
- JSON APIという性質上、一部ヘッダーの必要性は低い可能性があるが、クライアントやブラウザの脆弱性予防の観点では適用の必要性が高い
3. OAuth標準への理解不足の痕跡
- Public client対応 のために、OAuth 2.1で廃止されたimplicit grant方式を実装している
- 実際にはこの機能はPKCEやCORS緩和で十分に置き換え可能である
- Claudeがimplicit grantを推奨したように見えるが、実際のトークン発行段階では適切に検証していない
- Basic Auth処理の不備: OAuthでは特有のURLエンコード方式が必要だが、それが抜けている
- クライアントシークレットにコロンが含まれる場合に発生し得る副次的なセキュリティ問題がある
- ただし、このライブラリはクライアントID/シークレットを自前で生成するため、形式を制御しやすい構造になっている
4. トークンID生成コードのセキュリティ問題
- トークンIDのランダム文字列生成方法に 統計的な偏り (biased) が存在する
- エントロピー低下により攻撃しやすくなる可能性はあるが、実際の脅威は限定的である
- 「すべてのコード行が専門家にレビューされた」という主張に反して、初期コミットの時点でバグがそのまま存在 していた
- 初日に1人の開発者がメインブランチへ21回直接コミットした履歴など、体系的レビューの不足を示唆している
暗号化機能とLLMとの相互作用の事例
- トークン保存領域の暗号化設計は 人間が主導 し、実装をClaudeが支援した
- トークンごとにpropsを暗号化し、各トークンについて対称鍵をラップする方式が採用されている
- Claudeが途中で誤った設計を提案すると、エンジニアは 意図とセキュリティ上の狙いを明確に示して 修正させた
- 例: SHA-256ハッシュをラップ鍵として使う場合に露呈する脆弱性を指摘し、HMACベースへ変更した
- PBKDF2の提案に対しては性能面の非効率を指摘し、32バイトのHMAC鍵を使う形に調整した
- この過程は、AIと協働する際に高度なドメイン知識が必要 であることをよく示している
- 致命的な欠陥は、非専門家であれば認識すら難しい可能性がある
総評と示唆
- 初版としては 完成度はまずまず だが、そのまま実サービスに適用するにはリスクが大きい
- OAuthプロバイダー開発は本質的に 非常に厳格なセキュリティ・機能検証作業 を必要とする
- 大企業レベルでは数十万件の自動テストと多層的なセキュリティ点検が一般的である
- LLMベースの自動コーディングを「簡単に」適用できる分野ではない
- プロジェクトのコミット履歴は、LLMがどの程度まで補助的に機能できるかを興味深く示している
- ただし一部の欠陥は、LLMにも人間にもありがちなミスであり、Stack Overflowの回答など既存コミュニティでも同様に見られる
- 緻密さと注意深さが重要なコード領域では、AIと人間の双方に細心の注意が必要 である
- LLMを活用してコードをレビューしたり、その結果を信頼したりするには、自らの実装経験とSystem 2的思考が不可欠 である
- 単純・非中核業務であれば十分にLLMへ任せられるが、認証やセキュリティに関わる主要システムは専門家主導で設計・実装するのが望ましい
2件のコメント
CloudflareがClaudeとともにOAuthを構築し、すべてのプロンプトを公開
Hacker Newsの意見
この事例を見ると、LLMとやり取りするには多くのドメイン知識が必要だとよく分かる。たとえば Claude が途中ででっち上げた「致命的欠陥」に、一般の開発者なら気づけないかもしれない。PBKDF2 への変更を不自然だと感じられるのも、ドメインの専門性があるからだ。私の結論は、LLMを効率よく活用するには、実力のあるレビューアと「リーダー」が必要だということ。もしそのテーマについて LLM と同程度しか知らないなら、重要度の低い仕事に限るか、すべての出力を検証できるだけの十分な時間的余裕が必要になる
今後こうした新しい環境で、ドメイン専門家がどこから生まれてくるのか気になる。結局、誰がここまで深く理解する人間になれるのかという話になる
「よく知らない分野でだけ LLM を使い、専門家なら自分でコードを書く」という意見を聞くたびに不思議に思う。むしろ専門家ほど LLM の出力をより正確にレビューできるし、自分が欲しいものをドメイン専門家らしいやり方で説明できるほど、成果物は良くなる。ある意味では当然の話だ（LLM は統計的に生成されたテキストエンジンなのだから）
LLM は、デフォルト値の追加や例外処理、各種の回避策をあまりにも簡単に入れがちだ。だから一見動いているように見えても、実際には問題があるか、すぐ壊れるコードが簡単にできてしまう。私の
CLAUDE.mdでも何度もこの点を強調しようとしたのに、しばしばそういう結果が出続けた私は LLM で k8s のデプロイ作業の大半を処理した。すぐ動く結果は出るが、常に secret を使い、認証情報を平文でコミットしないよう何度も念押ししなければならなかった。こういうミスは本当に危険だ。教育用チュートリアルでは基礎に集中するためにセキュリティがよく省略されるので、LLM の学習データにそうした例が多すぎて、こういう出力になるのだと思う
時間が経てば、AI コーディングツールがドメイン知識を自分で調べられるようになると期待している。すでに登場している一部の「AI リサーチ」ツールはこの能力に非常に優れているが、まだコーディングツールとはうまく統合されていない。リサーチは公開インターネットだけでなく、社内文書にあるドメイン知識も参照できるだろう。ただし、一部の知識は人の頭の中にしかないので、利用者が自分で伝える必要がある
最近、Kafka consumer を AI の助けで書いてデータ移行を行った。こういう短期で、ゼロから作るプロジェクトで、しかも自分は言語（go）をかなり理解しているが久しぶりに使う、という状況では AI 活用の効果が最大化された。データがすべて1つの topic に入ってくるので、性能確保のためにかなり複雑な並列処理を実装した。全体として AI のおかげでおそらく2倍は速くなった感覚だった。特に go の文法をたまに忘れたとき、検索する代わりに AI にすぐ聞けたのが役立った。ただ、潜在的なバグが少なくとも4つ（そのほか明白なバグはもっと多い）潜んでいた。Kafka やマルチスレッドに慣れていなければ、そのまま本番に出していたかもしれない。大規模・長期プロジェクトでは改善は 10〜20% 程度だ。最新モデルではそういう流れになっている。全体として見ると、これはメモリ管理言語に移行したときに得られた生産性向上に近い。PM が開発者を置き換えるといった想像とはほど遠い（この3年の変化速度を見る限り）。むしろ本当の懸念は、中堅レベルの「技術嵐」級の開発者が AI によって10倍効率化すると、微妙なバグを見つけたり対処したりできず、かえって危険になることだ。シニア/スタッフ級エンジニアはレビューの洪水に耐えられない気がする。そしてジュニアからシニアへ成長する過程も、より脆くなるのではと心配だ。すでにコピペプログラマが問題なのに、AI によってこのパターンはさらに強化される。最終的には市場が解決するだろうが、何十年もかかるかもしれないという不安がある
AI が生み出すバグは本当に巧妙だ。私も AI にマルチスレッドのコードを書かせて、微妙なバグを実際に本番へ入れてしまったことがある。レビューやテストをしても、自分で手書きしたときほどの集中力は出ない。当面は、AI が書いたコードはありがちなバグを先回りして確認し、致命的な影響のない領域に限定して使う必要があると感じる
私も「重要な作業」では 10〜20% くらいの改善を感じる。本当の変化ではあるが、ソフトウェア開発の本質を変えるものではない。結局、Brooks の "No Silver Bullet"（銀の弾丸はない）命題の再確認だ
私も「中堅の技術嵐」論点には同意する。特にコンサル業界では、ベテランはコストに見合う価値が低いものとして扱われがちなのが現実だ。以前の私は作業の速い側だったし、後には非専門家の PM に短期的な解決策の弱点を説明するのに苦労した経験もある。大手 IT 企業ならこうした問題をすぐ見つけるだろうが、現実には金融や医療データを扱うコードが、安価な短期契約人材によって書かれている。こうした状況は LLM 登場前から問題だった。今はセキュリティに敏感な開発者にとって、さらに厳しい時代だろう
生成コードに微妙なバグが見つかったと言っていたが、そうしたバグを AI が生成したテストコードで自動検出するのはどうだろうと思う。もちろんテストコード自体にもバグはあり得るが、将来的には生成コードよりテスト結果だけを重点的にレビューするようになるシナリオも頭に浮かぶ
複雑な並列処理と言っていたが、それは partition と consumer-group の活用で解決できる領域ではないか、という疑問
LLM を積極的に信頼し、「崖から落ちるように」無批判に頼り切って仕事をする人を見ると、もどかしくなる。完全にブラックボックスに依存して作業し、検証まで全部任せるのは危険だ。しかも莫大なエネルギーを消費する仕組みであり、人を置き換える口実として使われることもある。こういう環境が人生を10倍良くするというのは、正直あまり信じられない
自分で開発したときと、他人が作った成果物（特に LLM 産のコード）を検証する過程を比べると、人間はしばしばもっともらしい見た目にだまされ、問題点をあまり批判的に受け止めなくなる傾向がある。コードの「見た目」もバグ発見に大きく影響する。これを検証するには、コードにわざとバグを混ぜ込み、コードレビュアーがそれを見つけられるか実験してみるのも一つの方法だ。自分の手で何かを実装すると、ずっとゆっくり、緻密に考え、細部に注意を払うようになる（だから予想外のバグも見つかる）。だから学習目的では、ツールを自分で「トイ版」として作ってみるのが一番良いとよく勧められるのだ。人間の認知構造に関わる話でもある
記事では不要なコメントは多くないとしていたが、実際のコードには
// Get the Origin header from the requestのような意味のないコメントがあるこういうコメントは LLM を使った痕跡だと分かるし、何の意味もないのでいつも消している
人間にはこうしたコメントは役に立たないが、LLM にとっては、下のコードの機能が自然言語で併記されていることで理解の助けになる、一種のロゼッタストーンのような役割を果たすのかもしれないと推測している。トークン消費が増える代償はあるが、実際に LLM がコメント過多のコードでより良い編集をするのか検証してみたい気もする
Claude には、こういう無意味で重複したコメントを非常に高頻度で書く傾向がある、という経験談
提案したいのは、コードのある branch を凍結しておき、AI たちを使って片方には脆弱性を作って隠すよう努めさせ、もう片方にはそれを見つけて修正する役割を与える、という実験だ。つまり、チェスの進化プロセスをコード開発にも適用してみるということ
このライブラリの作者は私だ（正確にはプロンプト作成者）。Neil ほどではないにせよ OAuth についてはある程度の専門家だし、彼がコードレビューしてくれたのは本当にうれしい。「YOLO CORS」については誤解があったが、これは単なる初心者ミスではない。この CORS 設定は、十分に考えたうえで意図的に行ったものだ。OAuth API（トークン交換、クライアント登録）エンドポイントと、OAuth bearer token が必要な API エンドポイントでのみ CORS を無効化している。これらのエンドポイントはブラウザ資格情報（cookie など）で認証されていないので、実際には CORS が守るものは何もないという判断だ。CORS の本質は、資格情報が自動で添付されないようにするセキュリティ上の壁だが、bearer token はクライアントが明示的に添付しなければならないため、クロスオリジンでも安全だ。実際、私は以前から CORS 仕様の策定者と議論したことがあり、ブラウザ資格情報ではなく bearer token を使ってこそ本当に安全だと主張してきた。一方、token ID 生成が非効率だという指摘については、「致命的」とまでは思わない。セキュリティ自体に問題はなく、アルゴリズムは後から自由に変更できるからだ。1人によって1日に 21 個の commit が main に上がっていた部分は、git 履歴の書き換えのせいで GitHub 上で日付が歪んで見えていただけだ。暗号実装への称賛は本当にありがたい。これは AI が作ったのではなく、私の明示的な設計指示があったからこそだ
「OAuth API では CORS ヘッダーを disable する」と言っていたが、実際には CORS ルールを無効化するように CORS ヘッダーを設定している、ということだ。文脈上は十分伝わるが、混乱するかもしれないので補足
Cloudflare がこのライブラリを実運用で使う計画があるのか気になる
人気の Stack Overflow 回答にも同じようなミスが多く、Claude もそういう場所から学んだのだろうと思うと心配になる。セキュリティホールやミスそのものよりも、社会全体の知識ベースが LLM 登場以前のインターネット上の人気回答で固定化されてしまうことのほうが、特に恐ろしい
ForgeRock の OAuth 実装には何百ものセキュリティバグがあり、何十万件もの自動化テスト、脅威モデリング、最高レベルの SAST/DAST、専門家レビューなどを尽くしてもそうだった、という話を見ると、OAuth が本当に厄介だと改めて実感する。中には「ゴミ捨て場の火事」のような実装だと言う人さえいる。もっとも、私は実際に仕様を読んだり実装したりしたことはない
OAuth 実装に関わるたび、いつも恐ろしく複雑だと感じた
OAuth は本当に厄介で、ニッチな論点が多すぎる
実際、新しく書いたコードには常にバグがあるものだ。複雑であるほどなおさらだ。だから企業は「battle tested（すでに現場で検証済み）」のコードやツールを使おうとする。冗談はさておき、Anthropic が自社の生成 AI を自社コードに実用的に使うやり方は興味深い。今後 MCP 認証 API にも使うのか気になる
「何十万件ものテスト」というのは量的拡大にすぎないのではないか、あるいは露骨に LLM が作ったものではないかと疑ってしまう。実際それを誰が保守しているのかも気になる
人々が自分のプロンプトを git にコミットする流れが一般化するのか、それとも単なるショーケース的なものなのか気になる