ウォレットの脇が開いていた

これは公開資料をもとにした個人の記録であり、特定資産の売買を勧めるものではありません。

情報基準：2026年8月17日午前8時42分、韓国時間

今日はウォレットの中より、その脇を長く見た。SafePalは約3万9,798人分の注文情報が無断で閲覧された事故を公表した。報告された原因は暗号技術の破綻でも、ハードウェアウォレットの金庫が開いたことでもない。注文照会のウェブ機能が「この人はこの注文の持ち主か」を十分に確かめなかった認可の問題だった。

玄関の鍵は丈夫だったが、宅配ボックスの鍵が複数の家に合ってしまったようなものだ。金庫が閉じていたことは大切だ。それでも住所や電話番号が漏れた瞬間、安心を伝える文字は少し小さくする必要がある。

1. 漏れたものと漏れなかったものを分けた

事故説明によると、氏名、メール、配送先、電話番号、購入情報が影響を受けた。一方、シードフレーズ、秘密鍵、ウォレットのパスワード、カード・銀行情報、政府発行の身分証情報は含まれず、ウォレットや資金が直接侵害された証拠も確認されていない。

この区別は欠かせない。「暗号資産ウォレットの事故」とだけ書けば、コインが盗まれたように読める。実際の次の危険は別にある。攻撃者は、誰がどのハードウェアウォレットを持つかを知り得る。偽ファームウェアの配送、サポート担当者のなりすまし、標的型フィッシングが急に本物らしくなる。

影響期間、件数、90日への保存期間短縮、フィッシングリンクの停止措置は、SafePalの説明を引用したセキュリティ報道に基づいた。検証時点で公式発表一覧から詳細告知を検索できなかったため、報道された範囲を超えて数字を広げていない。

出典：SafePal事故の報道、SafePalのセキュリティ案内

2. ログイン確認と注文の所有者確認は違う

公開された説明は、典型的なBOLAまたはIDORの問題に似ている。ログイン済みかだけを見て、その注文が本人のものかを確認しないと起こる。

GET /orders/1234

1234を1235に変えて別人の注文が見えるなら、UUIDに変えるだけでは直らない。番号を推測しにくくするのは表札を小さく書くことだ。鍵の確認ではない。

サーバーは毎回、次の関係を確かめる必要がある。

ログインした利用者 → 許可された役割 → オブジェクト所有者 → 許可された操作

管理者でも全注文を見る必要はない。サポート担当は割り当てられた問い合わせだけ、配送会社は配送に必要な最小項目だけを見るべきだ。権限は注ぎやすく、戻しにくい。塩を入れすぎたスープも似ているが、スープからはインシデント報告が来ない。

出典：OWASP Broken Object Level Authorization

3. 認可の回帰テストを機能テストの隣に置いた

注文APIを作るなら、正常系だけを試さない。二つのアカウントを用意して、次を自動化する。

1. 利用者Aが注文Aを読む — 許可。
2. 利用者Aが注文Bを要求する — 拒否。
3. 未ログイン利用者が注文を読む — 拒否。
4. 配送担当が決済・連絡先の全項目を読む — 拒否。
5. 失効したトークンで再試行する — 拒否。

テストではステータスコードだけでなく返却フィールドも見る。画面で電話番号を隠しても、API応答に原文が残っていれば開発者ツールが親切に真実を見せてくれる。時々、親切すぎる。

ログには誰がどの注文へアクセスしたかを残すが、個人情報そのものを複製しない。連続した注文番号の探索、異常な閲覧量、国の急な変化も警告対象にする。

4. 集めなければ事故後に追うものも減る

SafePalは関連データの保存期間を90日に短縮したと説明した。保存期間短縮は派手ではないが、効果は明快だ。サーバーにない古い住所は攻撃者も持ち出せない。

セキュリティ製品の脅威モデルには、製品コード以外も入れる。

• ストアと注文追跡プラグイン
• サポート・CRM接続
• 配送会社へ渡す項目
• バックアップと分析ログ
• 削除処理が実際に動いた証拠

「鍵を保管しない」と「注文情報をどう保管する」は同じセキュリティ説明に必要だ。分散型ウォレットも配送中は中央の倉庫を通る。

5. 今日の数字もラベルから見た

残りのニュースにも同じ教訓があった。ビットコインの6万3,000ドル割れは特定時刻の価格だ。ドイツ企業による米国への43億ユーロの直接投資は構成を見るべきフローで、既存事業がすべて撤退する証拠ではない。英国住宅の2%下落も成約価格ではなく、新規物件の当初提示価格だ。

数字を使う前に、三つのラベルを付ける。

• いつ測ったか
• 何を測ったか
• 何を含まないか

値札、レシート、口座残高はすべて数字だが、答える質問は違う。開発者にスキーマが必要な理由である。市場の判断過程は投資・経済：値札だけは信じなかったに分けた。

開発者チェックリスト

• 全オブジェクトAPIにサーバー側の所有者確認を置く。
• UUIDを認可の代わりにしない。
• 複数アカウントで認可の回帰テストを自動化する。
• 応答項目、ログ、バックアップまで個人情報の範囲に入れる。
• 保存期限と削除処理が運用で守られるか確認する。
• 市場データには出典、時刻、測定対象を付ける。

今日の結論は単純だ。最も高価な金庫を買ったなら、その横の注文照会ボタンも一度押してみよう。 攻撃者は製品説明で最も太い文字より、システムで最も薄い認可検査を先に探す。