すべての公開 Notion ページで、すべての編集者のメールアドレスが露出している

• 公開 Notion ページでは編集者 UUID が認証なしで露出し、1回の POST リクエストで 名前・メールアドレス・プロフィール写真 を取得できる
• 公開された社内 Wiki やドキュメントでは、そのページを編集した 従業員のメールアドレス がそのまま露出する可能性があり、Notion Community ページでも 13件のユーザー ID のうち 12件のメール を確認
• テストでは Notion 社員、[e-mail] のような service account、外部契約者が含まれ、別途 Cookie・トークン・認証手順 なしで照会可能
• getLoginOptions も認証なしで呼び出し可能で、各アカウントの パスワードログイン の可否と SSO 利用 の有無を判別できる
• この問題は 2022年の報告後も修正されておらず、公開ページを広く使う組織では PII 露出リスク が大きい状態

---

再現方法と露出する情報

• 公開ページの権限情報の中で Notion API が 編集者 UUID を返しており、この過程に 認証は不要
• Notion Community ページを対象にブロック権限から 13件のユーザー ID を確認し、これを /api/v3/syncRecordValuesMain に渡して 12件のメールアドレス を取得
  • 返却対象には Notion 社員、production service account である [e-mail]、そして 外部契約者 を含む
  • すべて 1つのページ だけで確認された結果
• 別途 Cookie、トークン、認証手順 なしでリクエスト可能

影響と追加リスク

• Notion ページは 社内 Wiki、採用掲示板、公開ドキュメント、オンボーディングガイド など多様な形で広く使われている
• site: notion.site 検索で 数千件 の公開ページを見つけられる
• こうした公開ページごとに、認証なしの API 呼び出し1回で 編集者のメールアドレスが露出する可能性 がある
• 従業員 500人のエンタープライズワークスペース が公開ページを共有している場合、1回のリクエスト で 500件の会社メールアドレスを取得できる
• rate limiting なし、1回で 50人ずつバッチ処理 が可能
• getLoginOptions もやはり 認証なしで呼び出し可能
• これを組み合わせると、各アカウントが パスワードログイン を使うのか SSO を使うのかを判別できる
• この組み合わせは credential stuffing の無料ターゲットリストにつながり得る
• 最初の報告は 2022年7月28日 に HackerOne に提出
• その後も約 4年近く 修正されていない
• 同じ問題を別途再発見して報告したが 重複処理 となった
• 再テストの結果でも 同じエンドポイント、認証なし状態、メール返却の継続 を確認
• HackerOne ではこの報告を informative に分類し、原文ベースで CVE の付与なし、バグバウンティなし だった
• 顧客 PII の露出 状態と規定
• 公開 Notion ページを利用しているチームは 共有設定の点検が必要

[cshj55]

Notion AI以降、もう……何のアプリなのかも分からなくなってしまったけど、
こんなこともあったんだな

[devsepnine]

NotionからObsidianに乗り換えてからは、使うことがなくなったけど…

[GN⁺]

Hacker News のコメント

• Notion の公開ページをウェブに公開すると、寄稿したユーザーの名前・プロフィール写真・メールアドレスがメタデータに含まれる可能性があると公式ヘルプに書かれているのを確認した。こうしたPII の露出が注釈のように埋もれている点のほうが、より問題に見えた
  • この欠陥自体もあきれるが、それをby designのように受け止める態度はさらにひどく感じられた
  • 自分も公開ページを使う Notion ユーザーとして、これは本当に筋の通らない設計だと感じた
  • 似たようなことが一部 CMS のRSS フィードでもあったのを見た記憶がある
• 自分は Notion の Max で、この問題は文書化されており、公開時に警告も出しているが、それだけでは不十分だと考えている。現在、公開エンドポイントで個人情報を除去するか、GitHub の公開コミットのようにメールプロキシへ置き換える案を検討中だ。そして見た目とは違って、1 分で終わる修正ではなかった
  • それでも、この問題が出てから4 年というのは長すぎると感じた
  • 実際にどんな警告文が表示されるのか気になった。自分が 1 か月前に公開ページを作ったときは、ページ内容が公開されるという意味にしか読めず、編集者のメールアドレスまで露出するとはまったく感じなかった
  • それでも Notion にはすでに1 分以上の時間が十分あったのではないかと思う
  • ここに来たついでに聞きたいが、Firefox で Notion がやけに極端に遅い理由も気になった
  • 2022 年にすでに報告されていて、性質上も明らかな不具合に見える以上、今ごろは修正されていると期待したのは過剰反応ではないと思う
• しばらく Notion を使っておらず、久々に見たが、以前はハイパーテキストの事例として勧めようかと思っていたサービスが、今ではAI workplaceやAI everything appのような文句を前面に出していて、完全に別物になった感じがした。いったい何があったのかと思った
  • 自分も数年使っていないが、いくつもの会社で誰かが Notion を強く推してチーム移行を進めるたびに、むしろ速度が大きく落ちるのをよく見た。冗談交じりに競合他社へ人を送り込んでNotion 導入をさせれば妨害工作になる、という話まで出た。自分の印象では学習曲線が予想より長く、少数の推進者—主に PM やオペレーション側—には時間を節約してくれる一方で、大多数には可読性中心の管理を強いた。雑然としていても現実を反映している業務を、きれいな表や整ったビューに無理やり合わせることで、見た目は良いが不正確な状態が組織全体に広がる感じだった
  • Notion はすでに何年も業務用統合アプリとしてポジショニングしてきたし、プロジェクト管理とドキュメント化が一体になった製品なら、AI が入ってくる流れも自然だと思った
  • 自分の基準では、Notion が「今さら」意味を失ったのではなく、もともと何でもやろうとするアプリであり、その結果として散漫で非効率なツールだった。そこに AI をさらに載せたのもその延長線上に感じられた
  • ここで言うhypertext の事例という表現が、正確にはどういう意味なのか気になった
  • 自分は Unix に慣れているので、この種のソフトウェアを日常でわざわざ使わずに済むこと自体がむしろ心地よかった
• この問題は少なくとも5 年以上前からあるイシューだと記憶している。実際、以前に誰かが自分の Notion ページを見て、自分の匿名性が破られたこともあった
  • もうプライバシーを守るには、本当にOPSECレベルでアカウントを分離して痕跡を管理しなければならないのかと思った
• タイミングが妙だった。ちょうど Claude にNotion vs Obsidianの比較をさせて HN に移ってきたら、すぐこの投稿が目に入って、かなりありがたかった
  • みんながたくさん推薦してくれて助かった。自分の用途は個人知識グラフではなく ADU を建てるための作業なので、タスク管理、インスピレーションボード、費用表、注文リスト、文書まで幅広く必要だった。そういう意味では Notion は依然としてかなり強力に見えたし、Logseq・Obsidian・Joplin・Trilium・Craft のようなツールは各自の領域では良くても、自分の要件には少し足りなく見えた。Anynote は悪くなさそうだったがウェブクライアントがなく、Milanote はインスピレーションボードの比重が大きいとき向きに見えた。結局、今回の問題さえなければ Notion はかなり魅力的な選択肢だったという考えは変わらなかった
  • 個人の知識ベースなら、プロプライエタリなサービスは避けろと言いたい。自分は Logseq が好きだが、だんだん abandonware のように見えてきたのも心配している
  • 自分のプロジェクトである hyperclast も一度見てほしい。Notion、Obsidian などとの比較ページも別にまとめてある
  • 自分は Outline をself-hostingして使っている。最新の AI 機能は少ないかもしれないが、Notion の代替として必要なものはほぼ揃っていると感じた
  • 自分は数年前に Obsidian からJoplinへ移行したが、完全な FOSS で、個人の Nextcloud インスタンスと同期できるので満足している
• 大企業はユーザーや従業員のセキュリティ・プライバシーをもっと真剣に扱うべきだと思った
  • もしかすると、大企業の取締役会や株主も法的構造の陰に隠れられないようにして、こうした問題に対して金銭的責任を負わせるべきだと思う
  • 企業は理由があって初めて動くものだと思う。結局はユーザー自身が自分のプライバシーをもっと気にかけ、必要なら製品を乗り換える意思を持たなければならない。非難だけでは売上は揺らがないので、会社としては大きく変わる理由がないと感じた
  • 今後はコンサル会社が、100 万トークンあたり何件の脆弱性修正が可能かを宣伝し、エンジニアリングチームは生成コードのマージ圧力を受けるようになる気がする。Dependabot や SonarQube のようにトークンを大量消費するセキュリティ PR レビュー・コードベース監査サービスも増えそうで、この分野は小さなチームが素早く ARR を作るのに向いた市場に見えた
  • 結局、こうした問題を本当に防ぐには、企業を実質的に罰する政治家と規制を有権者が選ばなければならないと思う
  • 現実には企業は利益しか見ていないと思う。できるだけ早く利益を出してエグジットし、次のベンチャーへ移る動機のほうがはるかに強く見えた
• そもそもサーバーがユーザーデータをほとんど保存せず、各ユーザーが自分のデータを保持して、必要なときだけオンデマンドで materializeする構造を考えたことがある。人為ミスによる漏えいは避けにくいので、最も根本的な解決策は最初から保存量を減らすことだと感じた。ただし、グループデータの組み合わせコスト、オフラインユーザーによって生じる集計問題、クライアントスクレイピングの防止、許可されないデータ改変の制御など難題が多かった。たとえば HN ユーザーごとの sqlite を置いて、サーバーが各自から投稿を取得するモデルも想像してみたが、1 人でも利用不能だと結果が欠けるため、現実的な難易度は高く見えた
  • 自分もそのアイデアは好きだが、結局は今のシステムに近い形へ戻っていきやすいと思う。ユーザーは複数のデバイスを使うので、結局は同期サービスが必要になり、その複雑さが増すと再び第三者に委ねることになって、FB・Google・Apple 型のログインとデータ管理の世界へ戻ってしまう気がした
• 自分は Notion を本当によく使っていて、統合もいくつか作ったが、全体として良いアプリだし、AI 活用も悪くなく、継続的に改善されていると感じる。今回の問題はぜひ直してほしいし、最近は API がかなり良くなって、database viewsも第一級オブジェクトとしてサポートされるようになったのはうれしかった。公開 API にはまだ細かく望む点が少しある
• ツイートはほんの数言の短文なのに、そういうものまでわざわざLLMで書く必要があるのかと思った
• Notion の macOS アプリは、自分が使ったソフトウェアの中でも指折りにひどかった。プラットフォームのデザイン慣習をほとんど無視している感じだった
  • こういうウェブラッパーアプリ文化は早く消えてほしいと思う。あまりに多くのサービスがこの方式でユーザー体験を壊していると感じる
  • インストールして 1 時間ほどしか経っていないのに、サービスワーカーが7GB のディスクを使っていて驚いた。アップロードしたファイルもほとんどないのに、何をそんなにキャッシュしているのかわからなかった
  • 結局、Electronだという点がすべてを説明していると感じた
  • 実際、これは本物の macOS アプリではなく、単なるウェブアプリのパッケージ版に近いと思った