例のサイゼイヤをIPAに通報した
まず、サイゼリヤの「安さを徹底追求する」企業努力にはとても感謝しています。
だからこそ、この高校生（自称）の行為は、醤油ぺろぺろテロ行為と何ら変わりがないことを言いたいです。
彼がやったことは「やりすぎ」「法に触れる可能性」
彼がもし、本当にエンジニアとしてデベロッパーとしてクリエイターとして、将来を担っていきたいのであれば、サイゼリアのコードを解析した結果、容易に非公開APIを通じて、サイゼリヤのサーバーに到達する可能性があることを、まずIPAに報告すべきでした。
本件の問題は、 セキュリティホールを発見したことではなく、その後、その脆弱性を利用したことです。その時点でアウトですから、それをさらにOSSとして公開したことは、頂き女子りりちゃん事件（幇助）と変わりません。
IPAの「法令に抵触する可能性を危惧しております」報告
IPAに相談・報告すると、次のような返信をもらうことがあります。
本件の脆弱性について、
本来ウェブサイトで提供している機能以外の手段で、
API を用いて送信を行った結果、店舗側のサーバにアクセスされたものと認識しております。
IPA は法律の専門家ではないため確定的な判断をするものではありませんが、
法令に抵触する可能性を危惧しております。
「情報セキュリティ早期警戒パートナーシップガイドライン」でも
「発見者が心得ておくべき法的な論点」をご案内しております。
ご留意くださいますようお願いいたします。
情報セキュリティ早期警戒パートナーシップガイドライン
https://www.ipa.go.jp/security/guide/vuln/ug65p90000019by0-att/partnership_guideline.pdf
ガイドラインには「セキュリティホールを見つけても、ここまでにしておけ。それ以上は法に触れる」という指針が書かれています。
ガイドライン：付録３ 法的な論点について
付録３ 法的な論点について
１ 発見者が心得ておくべき法的な論点
発見者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
１－１．脆弱性関連情報の発見に際しての法的な問題
（1）関係する行為と法令の関係
a) ネットワークを用いた不正
- 例えば、脆弱性関連情報を利用して、アクセス制御機能を回避し、インターネット等を介してシステムにアクセスした場合には、不正アクセス禁止法（不正アクセス行為の禁止等に関する法律）に抵触します。
- 例えば、管理者の了解無く、他人のパスワードを取得し、それを用いて権限なしでシステムにアクセスした場合には、不正アクセス禁止法に抵触します。
- 故意にサーバの機能や性能の異常を来たそうとして何らかの行為をなし、コンピュータの性能を低下させたりした場合、刑法上の偽計（もしくは威力）業務妨害罪に抵触する可能性があります。さらに、その妨害の程度によっては、刑法の電子計算機損壊等業務妨害罪にも抵触すると解される可能性があります。
b) 暗号化されている無線通信の復号化
- 暗号化されている無線通信を傍受し復号する行為（無線 LAN の WEPキーを解読して通信内容を復号すること）は、電波法109条の2に触れる可能性があります。
（2）不正アクセス禁止法に抵触しないと推察される行為の例
脆弱性の発見に最も関係が深い不正アクセス禁止法に対しては慎重な扱いが求められます。といっても脆弱性を発見する際に、必ずしも不正アクセス禁止法に抵触するとは限りません。以下に、不正アクセス禁止法に抵触しないと推察される行為の例を挙げます。
- ウェブアプリケーションの利用権者が、正規の手順でログインする等して通常のアクセスをした際に、ブラウザとサーバとの通信の内容を観察したところ、それだけで脆弱性の存在を推定できた場合。
- ウェブページのデータ入力欄にHTMLのタグを含む文字列を入力したところ、入力した文字列がそのまま表示された。この段階ではアクセス制御機能の制限を回避するに至らなかったが、悪意ある者に別の文字列を入力されれば、このサイトにセキュリティ上の問題が引き起こされかねないと予想できた場合。
- アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察されるURL中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。（ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。）
（3）IPAの対応と発見者の法的責任
IPA は、脆弱性関連情報の入手方法に関して関知しません。ただし、違法な手段で入手されたことが明白な脆弱性関連情報に関しては、受け付けないことがあります。
また、IPAが脆弱性関連情報を受け付けた場合でも、IPAは脆弱性関連情報の入手手段に関して合法であると判断したわけではありません。さらに、IPAが脆弱性関連情報を受け付けた場合、発見者の脆弱性関連情報の発見に係る法的責任が免責されるわけではありません。
１－２．脆弱性関連情報の管理および開示に際しての法的な問題
発見者の脆弱性関連情報の管理および開示に際しては、以下の法的な問題への注意が必要です。
- 脆弱性についての調査・報告は、その率直な交換により、ソフトウエアやウェブアプリケーションシステムのセキュリティが結果として強化され・向上するという側面があります。
- しかしながら、その情報については、悪用というデメリットがあるので、その点についての十分な配慮がなされるべきであり、その一つの方向性を提唱するのが、このガイドラインといえます。
- また、情報自体そのような性格をもつので、発見者についても脆弱性関連情報の管理および開示について真摯な態度が必要とされます。
- そのような真摯な態度を保つ限り脆弱性関連情報についての調査・報告は、社会的に有用なものと考えられます。
しかしながら、管理および開示について真摯な態度を欠く場合については、上述の限りではありません。そのような真摯な態度を欠く場合の具体的な例として以下があります。
a) 脆弱性関連情報の公表は、その情報の内容が真実と異なることを知っていた場合、あるいは、真実である場合であっても、特定人の名誉を毀損する意図で公表がなされ、かつ、公共の利益と無関係である場合には、刑法の名誉毀損罪に触れる可能性があります。
b) 特定人の信用を毀損する意図で事実と異なる脆弱性関連情報を、事実と異なると認識して公表がなされる場合には、刑法の信用毀損罪に触れる可能性があります。
c) 通常人に求められる程度の相当の注意をもって調査・検証したりしたのではなしに脆弱性関連情報であるとして公表し、かつ、脆弱性関連情報の開示に起因して損害が発生した場合、損害賠償責任等の民事責任を追及される可能性があります。
２ 製品開発者が心得ておくべき法的な論点
製品開発者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
(1) ソフトウエアの提供行為についていえば、セキュリティに問題が生じず、日頃の運用で安心して使えるというレベルのソフトウエアを提供することが、法律上、債務の本旨に従った履行（民法４１５条）として求められています。
(2) もし、提供したソフトウエアにおいて、設計上の問題、プログラミング上の問題、運用上の問題の如何を問わず、社会通念上、安心して使えるというレベルにいたらない箇所が生じている場合には、その点に対してサポートの約定の趣旨に従い対策をすべきことが求められています。
(3) もっともその対策方法の選択については、種々の考慮が必要になります。
この対策方法の選択に際しては、以下の点を論点として意識する必要があります。
(a) 上記の対策方法の選択について、状況に応じて債務不履行責任（民法４１５条）、不法行為責任（民法７０９条）の対象となる可能性があります。
(b) 提供の際の契約で、これを免除する場合については、消費者契約法の適用がある場合には、責任の全部免除が認められない場合がありえます。
(c) 製造物責任法上の問題として、現時点において、ソフトウエアそれ自体については製造物責任が問われないと一般に解釈されていますが、電気機器や電子部品その他の工業製品等に組み込まれたソフトウエアは動産である製造物ですので製造物責任法に定める責任規定の適用がなされることがありえます。
３ ウェブサイト運営者が心得ておくべき法的な論点
ウェブサイト運営者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
- ウェブサイト運営者と、ウェブサイト利用者との間においては、そのウェブアプリケーションの利用に際して、一定の契約関係にはいると考えられます。そして、ウェブサイト利用者が、そのサイトに一定の個人情報等をゆだねる場合には、ウェブサイト運営者は、そのサイトの利用契約に付随した義務として一定レベルのセキュリティ維持を果たすべき義務を負担していると考えることができます。
- 各サイトに「プライバシポリシ」等が記載されている場合には、その内容をも前提にウェブサイト利用者とウェブサイト運営者は、契約関係にはいると考えられます。
- この場合、ウェブサイト運営者において、上記のセキュリティ維持等について過失がある場合、その過失による損害賠償の責めを免れるような規定は、消費者契約法上、全部免責の規定については無効となることがあります。
サイゼリヤ側のセキュリティ設計上の問題
あのコードが「動いてしまう」原因
サイゼリヤの注文システムは「ブラウザでQRを読んだ客だけが使う」という前提で設計されている。しかし実際には ブラウザが行う制約をすべてサーバー側で再検証していない。これがこのリポジトリが成立する根本原因。
- サイゼリヤ自体の問題
| 問題 | 影響 | 根本原因 |
|---|---|---|
| Origin/Referer の無検証 | 任意HTTPクライアントからAPI呼び出し可能 | CORS をブラウザ任せ |
| スタッフ呼び出しに認証なし | 全国全テーブルへの業務妨害が可能 | 「内部用」前提のAPI設計 |
| アイテム検索がほぼ認証なし | 全メニューの列挙・スクレイピング | セッション検証が不徹底 |
| QRコード = セッション権限の全て | QR漏洩で他人による注文が可能 | 物理的存在の技術的証明なし |
| 保護APIと非保護APIが混在 | 攻撃対象が広い | 一貫したアクセス制御モデルの欠如 |
サイゼリヤ側の問題有無
「つまり、サイゼリヤの注文フォームには、セキュリティ上の問題があるということか？」
→「YES」
だからといって、このセキュリティ脆弱性を利用して良いことにはなりません。
正しい手順はIPAに通報。
本件の脆弱性関連情報届出制度（ウェブアプリ対象）番号
IPAへの届出は 脆弱性関連情報届出制度（ウェブアプリ対象）で、番号体系は以下の通りです。
- 該当するCWE番号
| 脆弱性 | CWE番号 | 名称 |
|---|---|---|
| スタッフ呼び出しAPIに認証なし | CWE-306 | Missing Authentication for Critical Function https://jvndb.jvn.jp/ja/cwe/CWE-306.html |
| Origin/Referer のサーバー側未検証 | CWE-346 | Origin Validation Error https://jvndb.jvn.jp/ja/cwe/CWE-346.html |
| 全体的なアクセス制御の不備 | CWE-284 | Improper Access Control https://jvndb.jvn.jp/ja/cwe/CWE-284.html |
| QRコード知識のみで認証成立 | CWE-287 | Improper Authentication https://jvndb.jvn.jp/ja/cwe/CWE-287.html |
主訴は CWE-306 が最も当てはまる（認証なしで物理的なアクションを引き起こせる）。
IPAへの届出内容
脆弱性を確認したウェブアプリケーション等に関する情報
脆弱性を確認したウェブサイトのURL
https://■■■■■ （サイゼリヤの注文フォーム）
脆弱性の確認日
2026年5月5日
脆弱性の種類
その他（認証・認可の不備）
CWEとの関連付け
-
CWE-306: Missing Authentication for Critical Function
スタッフ呼び出しAPI（■■■■■.php）が、セッション・CSRFトークン不要で動作し、物理的アクションを任意の第三者が引き起こせるため。 -
CWE-284: Improper Access Control
アイテム検索API（■■■■■.php）がOrigin偽装と組み合わせることで、認証なしに全商品・全店舗のメニュー情報を総当たりで取得できるため。 -
CWE-346: Origin Validation Error
サーバー側でOrigin・Refererヘッダーの検証を行っていないため、任意のHTTPクライアントからヘッダーを偽装してAPIを呼び出せる。ブラウザが行うCORSの制約がサーバー側で再現されていない。 -
CWE-287: Improper Authentication
注文セッションの認証根拠がQRコードのURL知識のみであり、「物理的に席にいること」をサーバー側で検証していない。QRコードが写真等で流出した場合、第三者が遠隔から正規ユーザーとして注文操作を行える。
脆弱性の発見に至った経緯
【発見のきっかけ】
X（旧Twitter）上で、サイゼリヤの注文システムAPIを利用したOSSが公開されているという投稿を目にした。その投稿をきっかけに公開されたソースコードを調査したところ、サイゼリヤのAPIに認証不備が存在することを確認した。
【具体的な調査手順】
- X投稿（ https://x.com/nakasyou0/status/2050830565117759656 ）を確認した。
- 関連するOSSリポジトリ（ https://github.com/■■■■■/■■■■■ ）のソースコードを読んだ。
-
packages/client/src/client.tsのスタッフ呼び出し処理を確認したところ、リクエストに必要なパラメータが店舗ID（■■■■■）・テーブル番号（■■■■■）のみで、セッションIDやCSRFトークンが含まれていないことを確認した。 -
scripts/get-all-menu.tsを確認したところ、Origin・Refererヘッダーを本サービスのものに偽装するだけで、アイテム検索API（■■■■■.php）へのアクセスが通過し、全店舗・全アイテムコード（0000〜9999）を総当たりでスクレイピングできることを確認した。サーバー側でOriginの検証が行われていないため、ブラウザ以外からの任意のHTTPクライアントによるアクセスが可能な状態になっている。
【発見した内容】
スタッフ呼び出しAPI（■■■■■.php）は、正規の来店客かどうかを検証する仕組みがなく、インターネット経由で誰でも任意の店舗・テーブルへのスタッフ呼び出しを実行できる状態にある。
以上の経緯から、CWE-287（不適切な認証）、CWE-306（重要な機能に対する認証の欠如）に該当する脆弱性が存在すると判断した。
脆弱性であると判断した理由
-
観測した事実:
■■■■■.phpへのPOSTリクエストに必要なパラメータは■■■■■（店舗ID）・■■■■■（テーブル番号）・■■■■■のみ。Cookie・セッションID・CSRFトークンは一切要求されない。店舗IDとテーブル番号はいずれも小さい整数値で、推測可能な情報である。 -
本来あるべき挙動: スタッフ呼び出しのような物理的アクションを引き起こすAPIは、有効なセッションCookieまたはCSRFトークンにより、正当な来店客からのリクエストであることをサーバー側で検証すべきである。
-
差分: サーバー側でセッション検証が行われていないため、任意のHTTPクライアントから直接APIを呼び出せる状態になっている。
-
そのため、本APIはCWE-287「Improper Authentication」、CWE-306「Missing Authentication for Critical Function」に該当すると判断した。
脆弱性により発生しうる脅威
可用性への脅威（主要）:
店舗IDとテーブル番号を列挙することで、全国約1,500店舗の全テーブルに対して大量のスタッフ呼び出しを行う業務妨害が技術的に可能である。
機密性への脅威:
Origin・Refererヘッダーを偽装するだけでアイテム検索API（■■■■■.php）のバリデーションを通過できる。全店舗・全アイテムコードの総当たりにより、全商品・全価格情報の無制限なスクレイピングが可能である。実際にこの方法で取得されたとみられるデータ（3,252件）が上記OSSリポジトリ内に含まれている。
完全性への脅威:
注文送信にはCSRFトークンが要求されており、現時点では直接的な注文改ざんは確認できていない。
検証コードの有無
あり（補足情報として）。
本脆弱性を発見するきっかけとなったOSSが、以下のとおり公開されている。
このリポジトリは本脆弱性を突く動作が可能なコードを含んでおり、実害リスクの高さを示す根拠となる。
なお、当該コードを用いて実際に攻撃を行ったわけではない。
脆弱性が再現した証跡
上記OSSの作者によるX（旧Twitter）動画投稿にて、システムが動作することが確認できる。
手元のスクリーンショット・ログは現時点では未取得。
ログファイルの有無
なし（現時点では未取得）。
ウェブサイト連絡窓口
（サイゼリヤ株式会社 公式お問い合わせ）
IPA以外の組織への届出について
サイゼリヤ株式会社への直接連絡は現時点では未実施。
なお、本脆弱性を突くOSSがGitHubおよびX上ですでに公開されており（上記参照）、攻撃コードが誰でも入手できる状態にある。迅速な対応を要請する。
深刻度と影響範囲
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
基本値: 5.3（Medium）
利用者数の根拠:
サイゼリヤは国内約1,500店舗（2025年時点）。全来店客が潜在的な影響範囲。
重要インフラへの影響:
飲食業は重要インフラ指定対象外のため、該当しない。
攻撃コードの公表の有無:
あり。GitHubリポジトリおよびX動画投稿として公開済み。
攻撃発生の有無:
現時点では未確認。ただし攻撃コードが公開されているため、潜在的リスクは高い。
（IPAからの進捗状況連絡は、こちらに追記していきます）
はてなブックマークのコメントはこちらです。
Discussion
コメント・議論は、すでに180件以上もついている、はてブのほうにどうぞ。
阿鼻叫喚・賛否両論ですが個人的にはこういう活動も必要だと思っています。評価します。
放置していたら、今はボヤ程度でもいずれエンジニアどころか日本の情報リテラシー荒れ放題ですよ。。
何がそんなにみなさんの気に食わないのかわかりませんが、そもそも…
この"通報"ってそんなに悪いことなんでしょうか？
当初から大勢がXで書いてましたが、「試みは面白いが大ごとになるからやめておけ」というのが良識あるエンジニアの総意でしたよね。
すぐに企業が動けない以上、IPAのこの制度を利用するのは当然の帰結ですし、それで企業にペナルティなどが発生するわけでもありません。
ルールに従って然るべき措置を講じただけ。
何を騒いでいるのか…これを騒ぎ立てるなら、元のリポジトリをそれこそ糾弾すべきです。
夜遅くに失礼しました。
認識がズレています。
批判されているのは通報したことではなく、
脆弱性が記載されている通報内容の詳細をzennに掲載したことです。
他者のコメントも読みましょう。
なんか記事者のサブ垢ぽいんだよな〜wあとこれだけはコメント非表示してないしWW
法に触れるかは私には分かりませんが、良い試みと思います！✨
当記事による仕様公開が脆弱性拡散に繋がるという指摘がありますが、それなら件のリポジトリにも同じことが当てはまりますから、通報自体には一定の妥当性はあるんだろうと思いましたー