Hotdry.

Article

Notion 公开页面编辑器邮箱泄露漏洞：技术根因与缓解方案

深入分析 Notion 公开页面中编辑器邮箱批量泄露漏洞的技术根因，定位 loadPageChunk API 权限控制缺陷，提供检测与修复方案。

2026-04-19security

在数字化协作工具日益普及的今天，数据隐私已成为企业安全建设的核心议题。2025 年至 2026 年期间，安全研究人员多次发现并披露了 Notion 公开页面中存在的编辑器邮箱泄露漏洞，该漏洞允许未经授权的用户通过特定 API 端点批量获取页面编辑者的个人信息。本文将从技术层面深入分析这一漏洞的成因、影响范围，并提供可落地的检测与修复方案。

漏洞概述与发现背景

Notion 作为全球领先的协作平台，为数千万用户提供文档管理、知识库建设和团队协作服务。当用户将页面设置为「公开分享」（Public Share）时，理论上该页面仅应向互联网访问者展示页面内容本身，而不涉及任何可识别个人身份的信息。然而，安全研究人员的逆向工程分析发现，Notion 的前端应用在加载公开页面时，会通过内部 API 端点获取并缓存大量元数据，这些数据中包含了页面编辑者的用户名、邮箱地址乃至账户标识符。

这一漏洞的核心问题在于权限控制的边界模糊。Notion 的前端在渲染公开页面时，错误地将本应仅对认证用户或页面协作者可见的元数据，通过未做充分过滤的 API 响应暴露给了任何访问该公开页面的用户。攻击者仅需创建一个脚本批量请求公开页面的 API 端点，即可大规模收集编辑者的邮箱地址，进而实施精准钓鱼攻击、暴力破解或社交工程操作。

技术根因分析：loadPageChunk 端点的权限缺陷

深入分析该漏洞的技术根因，需要从 Notion 前端的 数据加载机制说起。当用户访问一个 Notion 页面时，前端应用会调用一系列内部 API 端点来获取页面的完整内容，其中最重要的端点之一是 loadPageChunk。该端点设计用于分块加载页面内容，以提高大型页面的加载性能和用户体验。

问题出现在 loadPageChunk 端点的响应数据结构中。在正常业务流程中，该端点返回的响应包含页面的所有块（Block）数据、页面属性、以及与该页面关联的用户信息。对于私有页面，这些用户信息包括编辑者的显示名称、头像以及邮箱地址 —— 这些信息仅对已通过身份验证的协作者可见。然而，当页面被设置为公开分享时，Notion 的服务器端并未对这一用户信息字段进行充分的脱敏处理，导致 loadPageChunk 端点仍然返回编辑者的完整用户资料。

具体而言，漏洞的技术细节如下： Notion 的页面数据模型中，每个块（Block）都维护了一个 created_by 和 last_edited_by 字段，这些字段引用内部用户对象。当公开页面通过 loadPageChunk 加载时，服务器返回的用户对象包含了 email 字段，而该字段的可见性检查仅在 UI 渲染层进行，并未在后端 API 响应层面实施。这意味着即使用户在浏览器中看不到邮箱（因为前端代码跳过了渲染），但通过直接调用 API 或使用浏览器开发者工具查看网络请求，攻击者可以完整获取这些敏感信息。

此外，另一个相关端点 loadCachedPageChunks 也存在类似的权限控制缺陷。该端点主要用于预加载页面的缓存数据，同样会将编辑者信息作为页面元数据的一部分返回。安全研究人员的测试表明，即使是没有任何 Notion 账户的匿名访问者，只要知道公开页面的 URL，就可以构造相应的 API 请求并提取编辑者的邮箱地址。

影响范围评估

从影响范围来看，这一漏洞的严重性不容忽视。首先，受影响的是所有将页面设置为公开分享的 Notion 用户及其协作者。根据公开讨论和研究报告，任何使用公开页面功能并包含协作者编辑历史的页面，都可能暴露所有曾参与编辑的用户的邮箱地址。这意味着即使用户只是偶然编辑了一次公开页面，其邮箱也可能被永久记录在页面的元数据中。

其次，影响的用户规模极为庞大。Notion 在全球拥有超过一亿用户，其中相当比例的用户和团队会使用公开页面功能来分享文档、简历、作品集或知识库。特别是在个人品牌建设、内容创作和开源项目文档等场景中，公开页面被广泛使用。因此，这一漏洞可能涉及数百万用户的个人隐私信息泄露。

最后，漏洞的可利用性极强。攻击者无需任何高级技术手段或特殊权限，只需使用简单的脚本批量请求公开页面的 API 端点，即可自动化收集大量邮箱地址。与传统的网络爬虫不同，这种攻击直接针对 Notion 的内部 API，数据获取效率更高，且难以被传统的反爬虫机制检测。

API 权限控制缺陷的深层问题

从安全架构的角度分析，这一漏洞暴露了 Notion 在 API 权限控制层面的几个深层问题。

第一，后端数据过滤与前端渲染的职责边界不清。正确的数据安全实践应该是：服务器端在返回数据之前，根据请求者的权限级别对敏感字段进行过滤或脱敏处理。然而，Notion 的实现方式是将这部分职责交给了前端 —— 服务器返回完整数据，前端根据权限决定是否渲染。这种设计在面对 API 直接调用时完全失效，因为攻击者可以绕过前端逻辑直接获取原始数据。

第二，公开页面与私有页面的数据模型未做充分隔离。在理想的设计中，公开页面应该使用一个独立的数据视图，其中不包含任何与用户身份相关的敏感元数据。但 Notion 的实现似乎使用了统一的数据模型，只是依靠前端条件判断来控制显示，这导致了权限边界的模糊。

第三，API 响应缺乏敏感字段的显式标记。安全的设计应该在 API 响应中明确标记哪些字段包含敏感信息，或提供权限上下文信息，以便客户端正确处理。但在 Notion 的案例中，API 响应没有任何权限相关的元数据，客户端无法判断某个字段是否应该被渲染。

检测方案：如何识别邮箱泄露风险

对于使用 Notion 的企业和个人用户而言，了解自身页面是否存在邮箱泄露风险至关重要。以下是几种可行的检测方法。

首先，用户可以手动检查公开页面的网络请求。打开浏览器的开发者工具（按 F12 或右键选择「检查」），切换到「网络」（Network）标签页，然后访问目标公开页面。在网络请求列表中，搜索 loadPageChunk 或 loadCachedPageChunks 端点的响应。打开响应内容后，搜索 @ 符号或 email 字段，如果发现任何邮箱地址，说明该页面存在泄露风险。

其次，可以使用自动化脚本进行批量检测。以下是一个简化的检测脚本示例，用于验证特定公开页面是否泄露编辑者邮箱：

import requests

def check_email_leak(page_url):
    # 提取页面 ID
    page_id = page_url.split("-")[-1]
    
    # 构造 API 请求
    api_url = f"https://notion.so/api/v3/loadPageChunk"
    headers = {"Content-Type": "application/json"}
    payload = {
        "pageId": page_id,
        "chunkNumber": 0,
        "limit": 100,
        "cursor": {"stack": []},
        "verticalColumns": False
    }
    
    response = requests.post(api_url, json=payload, headers=headers)
    data = response.json()
    
    # 检查响应中是否包含邮箱
    emails = set()
    def extract_emails(obj):
        if isinstance(obj, dict):
            if "email" in obj:
                emails.add(obj["email"])
            for value in obj.values():
                extract_emails(value)
        elif isinstance(obj, list):
            for item in obj:
                extract_emails(item)
    
    extract_emails(data)
    
    if emails:
        print(f"[!] 发现泄露邮箱: {emails}")
        return True
    else:
        print(f"[-] 未发现邮箱泄露")
        return False

需要说明的是，上述脚本仅用于安全研究和漏洞检测目的，使用时应当遵守相关法律法规和 Notion 的服务条款。

第三，用户可以借助第三方安全评估工具。一些安全公司提供的 SaaS 平台可以自动化扫描公开页面的数据泄露风险，包括邮箱、敏感信息等的暴露情况。这些工具通常提供更全面的检测能力，能够覆盖多种泄露场景。

修复方案与缓解措施

针对这一漏洞，Notion 官方已经在后续版本中陆续推出修复措施，但用户自身也应采取主动的防护策略。

从平台层面，Notion 应该实施以下技术修复：第一，在服务器端实现基于请求者权限的数据过滤，无论请求来自前端还是直接 API 调用，都应按照统一的权限规则返回数据；第二，为公开页面创建独立的数据视图，完全排除用户敏感信息；第三，在 API 响应中增加权限上下文信息，帮助客户端正确处理权限边界；第四，增加 API 调用的频率限制和异常检测机制，防止大规模自动化数据收集。

从用户层面，以下措施可以有效降低风险：

限制公开分享的使用。最直接的防护措施是避免将包含敏感协作历史的页面设置为公开分享。如果仅需分享内容本身，可以考虑使用 Notion 的「导出为 PDF」或「发布为静态网站」功能，这些方式不会暴露底层页面的元数据。

定期审查公开页面列表。Notion 用户应当定期检查自己的工作区，清理不再需要的公开页面链接。特别是在团队协作场景中，应当建立公开分享的审批流程，避免随意分享。

使用匿名协作功能。对于需要公开协作的场景，可以考虑创建专门的工作区，使用不包含个人邮箱的专用账户，以降低个人身份信息泄露的风险。

关注 Notion 安全更新。保持 Notion 客户端和浏览器插件更新到最新版本，以便获得官方发布的安全修复。

总结与安全建议

Notion 公开页面编辑器邮箱泄露漏洞是一个典型的 API 权限控制缺陷案例，它提醒我们数据安全不仅依赖于前端的可见性控制，更需要在后端 API 层面实施严格的权限检查。对于企业和个人用户而言，理解这些潜在风险并采取主动的防护措施，是保护数据隐私的关键一步。

在当前云服务高度普及的背景下，任何平台的数据泄露都可能产生连锁反应。企业和个人用户应当建立持续的安全监测机制，定期评估公开分享页面的风险，并随着平台安全能力的提升不断调整防护策略。同时，也期待 Notion 等协作平台在快速迭代中始终将安全作为核心设计原则，为用户提供更加安全可靠的协作环境。

资料来源

security