すべての公開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 アプリではなく、単なるウェブアプリのパッケージ版に近いと思った