Snapmart 本人確認書類の画像が認証なしで閲覧可能に｜URL直指定の設定不備とIDORの違い、保存先の点検

Snapmart（スナップマート）は2026年10月16日、本人確認書類を提出した一部のクリエイターについて、提出した画像を第三者が閲覧できる状態だった可能性があると公表しました。2019年3月頃から2026年10月8日まで、本人確認書類の画像が URL の直接指定により認証なしで表示される状態だったとしています。

原因として発表されたのは「画像の保存先の設定不備」です。スマートフォンアプリから提出された画像を保存するときに、認証なしで閲覧できる設定が付いていました。本記事は発表を時系列で整理し、ID を差し替えて他人のデータを見る IDOR とどこが同じでどこが違うかを示したうえで、対象者がやることと、開発者が自分の保存先で確かめることをまとめます。

BUCKET="example-kyc-uploads"   # 自分のバケット名に置き換える
aws s3api get-public-access-block --bucket "$BUCKET"
aws s3api get-bucket-policy-status --bucket "$BUCKET"
aws s3api get-bucket-ownership-controls --bucket "$BUCKET"

4項目がすべて true、IsPublic が false、BucketOwnerEnforced なら、バケット単位では公開を止める設定です。読み方と、ファイルごとの設定・コードの確かめ方は後半の節にあります。インシデントの読み方やほかの事案は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

Snapmart 本人確認書類の件のタイムライン

発覚後、Snapmart はシステムの改修を終え、その時点で保存されていた画像も削除または非公開にしたとしています。10月7日に「直ちに不備を解消」とし、期間の終わりを10月8日としている理由は、発表には書かれていません。

何が起きたか：認証なしの直接参照とIDORの違い

発表が述べているのは「保存先の設定不備で、URL を直接指定すると認証なしで表示された」ことです。どのクラウドサービスの、どの設定だったかは公表されていません。ここからは、一般にこの形の不備がどう起きるかの説明で、Snapmart の構成を推測するものではありません。

画像の置き場によく使われるオブジェクトストレージ（Amazon S3 や Google Cloud Storage など）は、ファイルやバケットごとに「誰が読めるか」を持ちます。アップロードのときに全員への読み取りを許す指定（S3 の ACL なら public-read）を付けると、そのファイルは URL を知っている人ならログインなしで取得できます。アプリの画面にログインが要っても、画像の URL がストレージを直接指していれば、アプリの認証は関係しません。

「IDOR 系」とまとめて呼ばれることもありますが、厳密には形が違います。IDOR は「ログインはしているが、他人のものを見られる」不具合で、今回の発表は「ログインしなくても見られる」状態です。OWASP Top 10:2025 はどちらも A01 Broken Access Control に入れ、公開するもの以外は既定で拒否することを最初の対策に挙げています。

URL やファイル名が推測されにくいことは、認可の代わりになりません。URL はログ、共有、端末の履歴などから外に出ます。この論点は連載の UUIDv7か連番か｜IDを推測されにくくしても認可漏れは防げない で、ID の差し替えを2つのアカウントで試す方法は IDOR（認可漏れ）の見つけ方 で扱いました。

Snapmart 本人確認書類を出したクリエイターがやること

・個別メールを確かめる：対象者には10月16日中にメールが送られました。配信を停止している、または登録アドレスが使えないと届かないことがあります。心当たりがあれば 専用の問い合わせフォーム へ
・なりすましの連絡に応じない：Snapmart は本人確認書類の再提出、口座やパスワードの問い合わせ、カード情報の入力を求めることは一切ないとしています。メールのリンクから入らず、アプリか公式サイトを自分で開いて確かめてください
・パスワード：別の環境で管理していて対象外のため、変更は不要としています
・マイナンバー：個人番号を隠さずにマイナンバーカードを提出した場合は、画像に個人番号が含まれた可能性があります。漏えいして不正に用いられるおそれがあると認められる場合、本人は市区町村に個人番号の変更を請求できます（番号法第7条第2項）
・心当たりのない契約や請求：現時点で不正利用などの被害は確認されていないとしていますが、不審な連絡や身に覚えのない契約・請求には注意してください

本人確認書類の画像には、氏名・住所・生年月日・顔写真がそろって写ります。取得の形跡は確認されていないと発表されていますが、ログの無い期間があるため、しばらくは身に覚えのない請求に気を配っておくと安心です。

開発者の対策：本人確認書類を既定で非公開の保存先に置く

発表では、不備はアプリから提出された画像の保存時に付いていました。一般に、Web とアプリでアップロードの経路が分かれていると、ファイルに付ける設定も別々のコードに散らばります。経路ごとに直すより、バケットの側で公開を受け付けないようにするほうが漏れにくくなります。

AWS の文書では、BlockPublicAcls は公開 ACL を付ける PUT を失敗させ、IgnorePublicAcls は付いている公開 ACL を無視します。ACL を無効にしたバケットは、ACL を指定しない PUT か bucket-owner-full-control だけを受け付け、それ以外の ACL を付けた PUT は AccessControlListNotSupported で失敗します。今の文書では新しいバケットは ACL 無効が既定ですが、何年も前に作ったバケットは作成時の設定のままのことがあります。切り替えると、public-read を付けているコードはアップロード自体が失敗するので、先にコードを探してから変えます。

署名付き URL は期限を区切った合鍵です。S3 互換のストレージ（SeaweedFS 4.48、SigV4、boto3 1.43.114）で確かめた結果は次のとおりです。

期限内は URL を持っていれば誰でも開けます。AWS の文書によれば、CLI と SDK で作る URL の期限は最長7日で、一時的な認証情報で作った URL はその認証情報の失効とともに使えなくなります。表示のたびに短い期限で発行し、発行する前に「この人にこの画像を見せてよいか」をアプリ側で確かめます。ここが抜けると、署名付き URL でも IDOR になります。

自分の保存先を確かめる：公開設定・ACL・コードの3か所

冒頭のコマンドはバケット単位の設定を見ます。S3 の動作を模した moto 5.2.4 と AWS CLI 1.46.1 で、公開ポリシーを付けたバケット（陽性）と、4項目を有効にしたバケット（陰性）を作って実行しました。

次は本人確認書類を置くプレフィックスの下で、全員（AllUsers）か AWS の全認証ユーザー（AuthenticatedUsers）に権限を与えているファイルを1件ずつ探します。

BUCKET="example-kyc-uploads"   # 自分のバケット名に置き換える
PREFIX="uploads/"              # 本人確認書類を置くプレフィックスに置き換える
aws s3api list-objects-v2 --bucket "$BUCKET" --prefix "$PREFIX" --query 'Contents[].Key' --output text \
  | tr '\t' '\n' | grep -v '^None$' | while read -r KEY; do
  aws s3api get-object-acl --bucket "$BUCKET" --key "$KEY" \
    --query 'Grants[].[Grantee.URI, Permission]' --output text \
    | grep -E 'global/(AllUsers|AuthenticatedUsers)' | sed "s|^|PUBLIC $KEY |"
done

public-read で置いたファイルと非公開のファイルを混ぜたバケットでは PUBLIC uploads/app/a.jpg http://acs.amazonaws.com/groups/global/AllUsers READ の1行が出て、非公開だけのバケットと、ファイルの無いプレフィックスでは何も出ませんでした。ファイルの数だけ API を呼ぶので、まずはプレフィックスを絞ってください。

最後に、アップロード時に公開の指定を付けるコードを、リモートの既定ブランチから探します。

git fetch --all --prune
BRANCH="origin/main"   # 既定ブランチに置き換える
git grep -nIiE 'public[-_]?read|makePublic|allUsers|allAuthenticatedUsers' "$BRANCH" --

TypeScript（ACL: "public-read"）・Python・Java（CannedAccessControlList.PublicRead）・GCS の predefinedAcl: 'publicRead' と makePublic()・Terraform の allUsers を置いた検体のリポジトリでは5ファイル6行を拾い、署名付き URL だけを使うリポジトリでは0件（終了コード1）でした。

影響範囲と、ログが無い期間の意味

対象は本人確認書類を提出した一部のクリエイターです。人数は発表にありません。画像は提出から約1年で自動削除されていたので、見られる状態だったのは各人の提出後およそ1年間で、今回の改修の時点で残っていた画像は削除または非公開になりました。

Snapmart は2020年5月以降のログを精査し、取得の形跡は現時点で確認されていないとしています。一方、2019年3月〜2020年5月の約1年はログが無く、確かめられていません。

開発する側にとっての教訓は、公開されたファイルへの取得が既定では記録に残らないことがある点です。S3 では、CloudTrail は既定でバケット単位の操作だけを記録し、ファイルへのリクエストはデータイベントを有効にしないと残りません（料金がかかります）。サーバーアクセスログはベストエフォートの配信です。Google Cloud の文書は、公開されたオブジェクトへのアクセスは Cloud Audit Logs で追えないとしています。個人情報を置く保存先は、ファイル単位のログを取るかどうかと、何年残すかを先に決めておきます。クラウドの鍵の側から守る手順は アクセスキー漏洩を防ぐ にまとめています。

続報では、対象の人数、ログ精査の結果、再発防止策（画像の保存・管理方式の改修、審査完了後の速やかな削除、クラウド環境の設定の定期点検）の進み具合を見ておくと、対応を見直しやすくなります。続報が出たら本記事も更新します。

参照ソース

• Snapmart「【重要】本人確認書類画像の第三者閲覧の可能性について（Snapmart）」2026-10-16
• Snapmart 専用問い合わせフォーム
• OWASP Top 10:2025「A01:2025 Broken Access Control」
• AWS「Blocking public access to your Amazon S3 storage」
• AWS「Controlling ownership of objects and disabling ACLs for your bucket」
• AWS「Sharing objects with presigned URLs」
• AWS「Logging Amazon S3 API calls using AWS CloudTrail」
• Google Cloud「Public access prevention」
• Google Cloud「Cloud Audit Logs with Cloud Storage」
• e-Gov 法令検索「行政手続における特定の個人を識別するための番号の利用等に関する法律」