アエナのECアプリで会員マイページが機械的に連続閲覧、最大81万7,215人の住所・電話番号・カード下4桁が対象 — パスワードが漏れなくても起きる会員アプリの点検点

アエナのECアプリで会員マイページが機械的に連続閲覧、最大81万7,215人の住所・電話番号・カード下4桁が対象 — パスワードが漏れなくても起きる会員アプリの点検点
Photo: Pexels (Pexels) / Omamori AI brand overlay

化粧品や美容商品、食品などを扱うオフプライスチェーン「アエナ」を運営する株式会社アエナは2026年10月14日、同社の「ECアプリ」で会員のマイページが第三者に不正に閲覧されていたと公表した。閲覧された可能性があるのは、アプリに個人情報を登録した本会員最大817,215人分の氏名・住所・電話番号・メールアドレスと、登録済みクレジットカードの下4桁・有効期限・名義などである。原因は「不正アクセスを通じた機械的な連続アクセス」とされ、詳細は調査中である。ログインパスワードやカード番号の全桁は流出しておらず、会員情報の書き換えや購入、退会の操作もされていない。それでも、マイページに表示される情報が80万人分まとめて読み取られた。この記事では公表内容を整理し、会員アプリやECサイトを持つ企業が自社で確かめる点をまとめる。

背景

同社の発表によると、システムログを解析した結果、会員マイページが不正に閲覧されていたことが10月13日5時58分に判明した。対象はアエナのアプリ会員(アプリに個人情報を登録している人)で、LINE会員や、Amazon・楽天など他のショッピングモールで購入した客は対象外である。

閲覧された可能性がある情報は、マイページに表示される次の項目である。

  • 基本情報: 氏名、フリガナ、住所、電話番号、メールアドレス、生年月日、性別、職業
  • 届け先情報: 登録された届け先の住所・氏名・電話番号(家族や知人など第三者宛を含む)
  • 設定情報: お気に入り店舗、メール配信設定
  • クレジットカードの一部: 登録カードの下4桁、有効期限、カード名義

一方で、カード番号の全桁とセキュリティコードは同社のデータベースやサーバーに保存していないため流出していない。ログインパスワードの閲覧・流出も無く、会員情報の変更、退会、購入の確定操作も行われていないことを確認したとしている。同社はECサイトへのアクセスを遮断し、対象となる可能性のある会員には順次メールで連絡している。

リスクの全体像

会員にとっての当面の危険は、届いた情報を使った詐欺の連絡である。同社も、同社や公的機関、金融機関を装った不審なメール・電話・SMSに注意するよう呼びかけている。今回は住所や電話番号に加えて、カードの下4桁・有効期限・名義まで揃っている。「ご登録のカード(末尾1234、有効期限○月)の確認が必要です」のように、本物の会員情報を織り込んだ連絡が届くと、受け取った人は本物と思い込みやすい。届け先情報には第三者の住所・氏名も含まれるため、会員本人以外にも連絡が届くおそれがある。

企業側から見て注目すべきは、パスワードが漏れていないのに80万人分の表示内容が読まれた点である。原因の詳細は未公表だが、「機械的な連続アクセス」という説明からは、短時間に大量のマイページを開く操作を、アプリやその裏側の仕組み(API)が止められなかったことがうかがえる。他社の事例では、ログイン後の画面で使う会員番号を順に変えるだけで他人の情報が返る作りや、他のサービスから流出したIDとパスワードの組み合わせを大量に試す手口(パスワードリスト攻撃)が使われてきた。アエナの件がどちらに当たるかは、今後の公表を待つ必要がある。

同じ型の被害は、このところ会員アプリを持つ企業で続いている。ローソンIDでは本人向けの表示の仕組みが悪用され、セイコーマートのアプリでは会員57万人分が閲覧された。会員アプリは外部の開発会社に作らせることが多く、画面の見た目は確認しても、裏側で「誰の情報を返しているか」まで発注側が点検していない場合が多い。

チェックリスト

  • 会員アプリやマイページが使う API で、会員番号やIDを書き換えると他人の情報が返ってこないか
  • 同じ接続元や同じアカウントから、短時間に大量のマイページ表示や API 呼び出しがあったとき、止めるか通知する仕組みがあるか
  • ログイン失敗が続く接続元を一時的に止める設定があるか。多くのIDに少しずつ試す攻撃も検知できるか
  • マイページにカードの有効期限や名義、届け先の全住所など、表示しなくても困らない情報を出していないか
  • アクセスログを何日分保存し、異常な件数を誰が見ているか。今回は社内のログ解析で発覚している
  • 開発会社との契約に、脆弱性診断の対象として API を含めること、異常アクセス時の連絡と遮断の手順が書かれているか

打ち手

会員アプリを持つ企業は、まず API の一覧を開発会社から受け取り、会員情報を返すものに印を付ける。そのうえで、ログイン中の本人以外の情報を要求したときに拒否されるかを、テスト用のアカウント2つで実際に確かめる。番号を順に変えて取得できてしまう作りが見つかれば、最優先で直す。

次に、回数の上限を決める。マイページの表示や会員情報の取得は、1人の会員が1分間に何十回も行う操作ではない。接続元ごと、アカウントごとの上限を超えたら一時的に止め、担当者に通知する。アエナは発覚後にECサイトを遮断したが、上限と通知があれば、全件が読まれる前に止められた可能性がある。

あわせて、表示する情報を減らす。カードの有効期限や名義は、会員が自分のカードを見分けるだけなら下4桁で足りる。届け先の住所も、一覧では一部を伏せて表示できる。表示しない情報は、閲覧されても流出しない。

アエナのアプリ会員は、同社を名乗るメールやSMSのリンクからカード情報やパスワードを入力しない。同社は、メール・SMS・電話でパスワードやカード情報を聞くことは無いとしている。カードの利用明細もしばらく確認しておきたい。

あわせて読みたい

Omamori AI の結論

アエナの件は、パスワードもカード番号も漏れていないのに、マイページに表示される情報が最大81万7,215人分まとめて読まれた事例である。会員アプリを持つ企業は、ログインの強さだけでなく、ログイン後に誰の情報をどれだけの速さで返しているかを点検し、回数の上限と表示する情報の削減を進めるべきである。

経営者視点で考えるべきこと

会員アプリは販促の要であり、会員数が増えるほど、1回の事故で影響を受ける人数も増える。アエナの会員は80万人を超えていた。外部に開発を任せたアプリでも、預かった会員情報の責任は運営会社にある。発注時の要件に「他人の情報を取得できないこと」「大量アクセスを止められること」が書かれているか、リリース後に API を含めた診断を受けたかを確認したい。もう1つは、表示する情報の見直しである。マイページの項目は、作った当初のまま増える一方になりやすい。表示を減らす判断は開発の手間がほとんどかからず、事故の際の被害を直接小さくする。

SHARE 𝕏 in f

あわせて読みたい