デートアプリをハッキングした経験（そしてセキュリティ研究者への誤った対応）

• Cerca という デーティングアプリで深刻な セキュリティ脆弱性 が発見された
• OTP が応答内に露出しており、電話番号さえ分かれば誰でもアカウントにアクセス可能
• 認証なしで開かれている複数の API エンドポイント から個人情報が容易に流出した
• ユーザーの 性的指向、メッセージ内容、身分証などの機微情報 が大量に露出した
• サービス運営側は研究者による責任ある報告にもかかわらず、適切な対応と告知が不十分

---

セキュリティを真剣に考えるべきスタートアップの重要性

• 近年、スタートアップ は市場投入を急ぐあまり セキュリティがおろそか になりがち
• 個人情報が集中する デーティングアプリ であるにもかかわらず、開発・運用の未熟さ によってユーザーが危険にさらされている

脆弱性の発見と通知の手順

• 2025年2月23日、Cerca 側にメールでセキュリティ脆弱性と関連問題 を説明した
• 2月24日には ビデオ会議を通じて詳細な脆弱性、対応策、今後の手順 を議論した
• Cerca チームは 深刻性を認識し、迅速な対処とユーザー通知の予定 を伝えた
• その後、何度も 進捗状況の問い合わせ を送ったが、4月21日時点で 回答も告知もない
• 独自に確認した結果、当該脆弱性はパッチ適用済み の状態だった

OTP 脆弱性と簡単なハッキングの流れ

• アプリのログイン過程で ワンタイムパスワード（OTP）がネットワーク応答にそのまま露出 していた
• 攻撃者は 電話番号さえ知っていれば誰でも簡単かつ迅速にアカウントへアクセス可能 だった

API エンドポイントへのアクセスと情報流出

• アプリのバージョンヘッダーを入力 するだけで、すべての API パスに接続できることが確認された
• /docs エンドポイントを通じて OpenAPI ドキュメント全体が露出 していた
• Burp Suite などのツールを活用し、アプリヘッダー・トークンの自動注入 によって API 制御が可能だった
• 一部のエンドポイントは ビジネスロジックのみ変更 するが、中核エンドポイントは深刻な個人情報を返していた
• user/{user_id} などを通じて個人情報、電話番号、さらにはアカウント乗っ取りまで可能 だった

大量の個人情報と身分証情報の露出状況

• 個人情報エンドポイントを通じて 性別、都市、誕生日、学校メール、身分証情報などの PII が大量に露出 していた
• 特に、national_id_verified などの身分証関連フィールドから パスポート・住民登録証画像など の機微ファイルへアクセス可能だった
• 攻撃スクリプトにより 6,117人のユーザーを識別し、207人は身分証情報まで入力済み であることが確認された
• イェール大学所属を示したアカウントも一部含まれていた
• Cerca 公式 Instagram 基準では 初週の1万人ユーザーに相当する規模 だった

実際の被害リスクと問題の深刻さ

• 性的指向、会話内容、身分証など極めて機微な情報が漏えい し、ストーキング、なりすまし、脅迫 など深刻な被害リスクがある
• Cerca は 「暗号化など業界標準を順守している」と案内 していたが、実際の運用実態とは一致していなかった
• ユーザーは直接検証できないため、アプリ提供者による積極的で責任あるセキュリティ管理 が不可欠
• 実際には 不特定多数がすでに大規模な個人情報を窃取していた可能性 もある

結論と責任あるセキュリティ文化の必要性

• 誰でも簡単にハッキングできるほど 脆弱なアプリ運用 は深刻な社会問題である
• ユーザーデータ保護 を最優先にしなければ、被害はリアルタイムで発生しうる
• セキュリティ研究者の報告に 積極的な対応とユーザー案内が不十分 だった Cerca の事例は他山の石である
• より安全なインターネット環境を構築するために、すべての開発会社はセキュリティ体制の確立を最優先 にすべきだ

[GN⁺]

Hacker Newsの意見

• このアプリが大学生たちによるかなり初歩的な出来の産物だと考慮しても、セキュリティとコミュニケーションには最善を尽くすべきだと思う。とはいえ、大手VCが資金を出している成人向け企業でさえこうした問題にぶつかって似たような振る舞いをしているのを見ると、学生に対してあまりに厳しくする必要まではないとも思う。記事リンクを共有する

  • 私は強く同意しない。「知らなかった」は免罪符にはならない。知らないまま強行したことのほうがむしろ大きな問題だ。これは未熟な運転手が無免許で事故を起こして人を傷つけたのと同じだ
  • 私もCercaについて情報を得ようとして元リンクを開いてみたが、2025年4月の記事で、約2か月前に作られたアプリを褒める内容だった。LLMが幻覚で作り出したゴミのようにも感じる。OPの言う通りCercaチームに2月に連絡したのなら、ローンチ直後に見つかった脆弱性か、何かおかしな状況のようだ。それでも「2か月前からある脆弱性」+「2か月前に学生が作ったサービス」ではある
  • 「Cerca Applications, LLC」という名前でアプリが公開されているなら、これが学生の作ったアプリだから少し大目に見てほしいと、どうやって人々が知れるのか分からない
  • この学生たちは別の勉強をしたほうがいい気がする
  • それは彼らを弁護しているように聞こえる。大学生が作ったアプリなら無条件で見逃すべき、という話ではない。The Facebookも最初は大学生が始めたものだ。Metaによる長年のプライバシー悪用とデータセキュリティ軽視にはすでに長い歴史がある。だから、こうした行為は言い訳できず、創業者の年齢や経験に関係なく、きちんと規制して罰金を科してこそ解決すると考える
  • パスポートや性的指向のような機微なデータを扱うなら、データを漏らしていると指摘された時点で最低限応答すべきだ。これは完全な大惨事であり、ここでのセキュリティ不在は絶対に容認できないレベルだ
  • アプリのセキュリティについて何も分からないなら、そもそもアプリを作るべきではないと思う。感情的な話になるが、友人たちがマッチングアプリを使っているのを見ると、彼らの情報が露出するのはあまりに恐ろしい。作った人たちは恥じるべきだ。セキュリティ研究者からの連絡にも返答しなかったのだから、その点についても恥じるべきだ。もし自分がそんなふうに無視されていたら、もっと直截な暴露文を書いていただろう。頼むからアプリ作りはやめてほしい

• 開発者として小規模な会社で働いていると、自分の個人的責任について不安になることがよくある。多くの企業はPCIやHIPAAのような規制を受けなくてもよい領域で運営されている。小さな組織では、セキュリティは組織全体の課題ではなくエンジニアリングの課題として扱われがちだ。プロダクトチームは機能、PMはスケジュール、QAはバグだけに集中し、セキュリティについて声を上げる人はまれだ。エンジニアも割り当てられた仕事だけやればよい、という空気がある。エンジニアがセキュリティまで面倒を見られればよいが、そうでなければPMなどから非難されることもある。そしていつもこんな言葉が聞こえてくる。「それにどれくらい時間がかかる？」「実際にそんなことが起きる確率はどれくらい？」「まずはMVPを早く出して、後で補おう」など。だから私は従業員として会社に言われたことだけをやることになる。しかし、ハッキングや漏えいで会社が訴えられたとき、自分だけが「もっとよく知っているべきだった」エンジニアとして責任を負わされるのではないかとしょっちゅう不安になる

  • 実質的にエンジニアであって、認証書類に署名して安全を保証する立場ではないのだから、安全でないと証明されても責任を負うことはないだろう
  • 会社がLLCやCorpなら、"corporate veil" によって守られることになる。記録上、犯罪行為をしたのでなければ責任を負うことはない。ただし、あらゆる企業規模においてセキュリティ標準の不在は大きな問題だ。常に新機能のリリースがセキュリティより重要視される
  • 小さな組織のエンジニアとして、こうしたリスクをチームに教育し、セキュリティのための開発時間を確保するよう強く主張するのが私たちの責任だと思う。簡単ではないが、この部分をおろそかにすると会社そのものが危険になりうる
  • 私なら、自分を守れるだけの法律知識を身につけ、違法な要求には書面で反論し、無視してよいという承認も必ず書面でもらう。ただ、小さなスタートアップではそれも難しいかもしれない。もし合法でないと感じるなら、ただ辞めるだろう
  • 「命令通りにやった」という弁明は好きではないが、こういう場合は必ず書面に残しておくべきだ。セキュリティ上問題があるとメールで残し、上司が「気にしなくていい」と返した証拠を確保する。私の知る限り、平社員クラスの従業員がデータ漏えいで法的責任を負うケースは見たことがない。たいていは誰も責任を取らず、会社が象徴的な罰金を払って終わる
  • 会社の役員でないなら、個人的責任を負うことはないと思う
  • 私の経験では、そういうことはない

• 研究者の法的責任を減らすには、アカウントをもう1つ作るか、友人の同意のもとでプロフィールを作ってアクセス権を得る程度でも十分だと思う。実際にデータをスクレイピングする必要はなく、たとえば自分のidが12345で友人のidが12357なら、その間のidで別アカウントのプロフィールにアクセスできることを示せばよい。すでに多くの人が言っている通り、何千人分もの個人情報にアクセスする必要はなく、脆弱性を立証して公開するレベルで十分だ

  • これは情報セキュリティ研究者なら誰でも知っている標準的で明確なやり方だ。機微情報をスクレイピングして証明したくなるかもしれないが、それは不要であり、むしろ独善的な行為だ

• この文章自体、かなり混乱しているように感じる。OTP（ワンタイムパスワード）を受け取るAPIが単純で、サーバー応答としてOTPが露出するため電話番号さえ分かれば誰でもアカウントにアクセスできる、という話のようだ。APIが単に otp/携帯番号 という形で、OTPがレスポンスに含まれて返ってくるというのだから、電話番号を当てさえすればコードも受け取れる構造なのだろう。そしてスクリプトでユーザーIDを列挙し、1,000回連続で空のIDが出たら止めるようにして、合計6,117人のユーザー、207人分の身分証情報、19人のYaleの学生を確認したと明かしている。だが、この程度の同意もなく他人の個人情報にアクセスしたのは、過去にweevがAT&Tをハックして刑務所に行った件に近い。規模が小さくても、この種の研究は法的に危険であり、セキュリティ研究者を保護しない法環境を著者が理解していないようで懸念される

  • APIが otp/番号 で最終OTPをそのまま返していた点に言及している。電話番号さえ合えばOTPを即座に受け取れる構造だという意味だ
  • Auernheimer事件の最初の起訴状を読むと、このケースとは違って犯罪意図を立証する十分な証拠があった。彼らには実際に個人情報を外部へ公開したという容疑もあり、今回の件はそこまで同一ではない

• 私にも似た経験があり、別のマッチングアプリでバグを知らせようとしても連絡がつかなかったので、創業者のプロフィールを「連絡ください」に変えてみたら、バックアップから復元されてしまった。数年後、Instagramの広告でそのアプリを見かけて再び試してみたところ、まだまったく同じ脆弱性が残っていた。APIエンドポイントさえ分かれば誰でも管理者権限、すべてのメッセージ/マッチングにアクセスできる。もう一度連絡してみるべきか悩んでいる

  • 連絡して責任ある開発者であることを示し、問題だけ開示して先へ進むのがよいのではないかと提案している

• パスポートや住所のような機微情報をアプリで収集するときは、本当に二度考えるべきだと思う。「学生が作ったアプリだから」と軽く流してよい問題ではない

  • 英国政府がポルノサイトへのアクセスに身分証を義務化しようと躍起になっているが、それがどんな結果をもたらすのか見ものだ
  • パスポートなどの身分証情報を入力させたなら、入力後にそれが外部へ露出する必要は決してない。UIで身分証データを見せるためのAPIなら、番号全体ではなく下数桁だけ返せば十分だ。マッチングアプリなら、ID認証済みかどうかを真偽値やenum（未認証/パスポート/運転免許証式）で返すだけでも十分だ。航空会社アプリのようにIDごとに選ばなければならないシステムは例外だが、たとえばUnitedのアプリも下数桁だけを表示するように、こうした内部APIも制限されてほしい
  • GDPR（EU一般データ保護規則）を参照しろというリンクを共有している
  • いっそ政府が運営する安全でプライベートな本人確認サービスが必要だと思う。あるいはAppleやGoogleのような「ほぼ政府」の役割を持つ企業が担うべきかもしれない
  • できる限りサードパーティーの本人確認サービスを使うのが一般的だが、ああいうサービスも本当に身分証画像までアプリに渡すのかは疑問だ

• OTPをAPIレスポンスにそのまま返すのは、あまりにもばかげた状況だ。理由が分からない

  • UIで入力値とすぐ比較できるようにしたのだろう。セキュリティを考えなければもっともらしく聞こえる。マッチングアプリは必要とする個人情報の範囲が非常に広いので、こうしたミスは恐ろしい
  • こうすればデータベース費用を一気に削減できる
  • OTPを生成したあと、DBまたはキャッシュのレスポンスをそのまま返して、POCやMVPでは雑にこういうモデルを使っていると見落としやすい
  • OTPが「ワンタイムパスワード送信要求への応答」でそのまま露出しているように見える。おそらくフレームワークがDBオブジェクト全体をシリアライズしてHTTPで返しているのだろう
  • HTTPリクエストを1回節約でき、UXも速くなるので、見た目にはよさそうに見える。Pinterestも以前のAPIで2FAシークレットまで含むあらゆる情報を露出していたことがある。報告して報奨金ももらったが、こうしたミスはビッグテックでも時々起こる
  • 私にも理解できない。フォーム構築を簡単にしようとして起きたミスとしか思えない

• Yale Daily Newsの関連記事リンクを共有している

• 個人情報を核廃棄物レベルで危険なものとして扱う法律ができてほしい。漏えいした場合、会社が倒産するだけでなく責任者も法的危機に直面するべきだと思う。今はユーザーデータの収集があまりにも簡単なうえ、漏れても謝罪して終わりになってしまう

  • PIIを核のように扱うのは行き過ぎだと思う。メールアドレスのように認証や連絡にしか使わないものはそれほど問題ではない
  • ホワイトカラー向けの刑務所にでも行くようになって初めて、きちんと関心を引けるのだろう

• iOSでCharle's Proxyというツールを今さら知った。昔はアプリのバイナリから直接文字列検索をしながらペンテストしていた。iOS専用アプリの解析では本当に大きな助けになりそうだ

  • いいツールなので勧める（ただし、SSL pinning があると効かない）