开发者工具 · UUID 生成器
顺序 ID 泄露业务数据：为什么公共 API 会暴露 UUID
· 为什么它很重要
uuid 密码学 浏览器 API
自动递增 ID 告诉外界您接了多少订单，并使每条记录都可枚举。这篇文章解释了公开 UUID 可以修复什么、不能修复什么，以及如何在不迁移的情况下引入它们。
您的发票号码告诉竞争对手您的数量 - /orders/10482 中的信息泄露
返回 /orders/10482 的 API 端点告诉外部人员的信息不仅仅是订单详细信息本身。数字标识符表明您已经处理了至少一万个订单，暗示了有关您的增长率的信息，并使每个订单都可以猜测。通过序列号进行简单循环即可检索所有记录，无需进行身份验证或权限检查。这种模式随处可见——URL、数据库密钥、发票号码和交易 ID——即使系统需要身份验证才能查看任何单个记录。问题在报告和分析中变得更加复杂。可以获取 /orders/1, /orders/2, 并继续访问 /orders/10482 的攻击者可以全面了解您的订单历史记录和趋势。
枚举和抓取 — 顺序 ID 如何将一条公开记录转换为所有记录
顺序模式揭示了订单到达时间、提及哪些产品以及定价模式的趋势。观察者了解您的业务增长或收缩的速度。这些仅从 ID 枚举中得出的信息可以为竞争策略提供信息，指导社会工程或为其他攻击提供时间信息。这种暴露不需要任何成本就能发现，并且会出现在 URL、浏览器历史记录、缓存页面和服务器日志中。这不是理论上的：竞争情报公司和好奇的工程师通常会从公开可枚举的 ID 中提取业务指标。订单号样本向任何有足够积极性收集数据和执行基本分析的人揭示了生产率和总量。
一段中的德国坦克问题 — 根据连续数字样本估计总数
枚举应用统计分析来估计总量并跟踪时间模式。如果第一个订单发生在已知日期，并且您捕获了一周内 10 个订单的证据，则平均间隔可估算总体比率。竞争对手、投资者和攻击者无需访问 ID 本身之外的任何客户数据即可获得您的速度。顺序标识符保证每个大于当前数字的 ID 都可以预测未来的订单；每个低于样本中最小值的 ID 都证实您之前的操作较小。历史数据点创建增长时间表并实现预测。同样的原则适用于各个行业：金融交易、货运订单、医疗记录以及任何公开序列 ID 的系统。
UUID 解决了什么问题 — 无法猜测的引用，并且 ID 本身没有增长信号
当从 RFC 9562 为版本 4 指定的加密安全源生成时，随机生成的 UUID 包含 122 位熵。该标识符不可猜测，不可枚举，并且不会向外部观察者透露任何有关增长率或数量的信息。知道 /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60 的攻击者无法预测下一个订单的 UUID 或以任何合理的信心向后遍历您的历史 ID。 UUID 本身成为唯一但完全不透明的引用。随机分布意味着多个查询不会向监控您的 API 的外部观察者揭示任何模式、没有进展、也没有速度信息。
UUID 无法解决的问题 — 不可猜测的 ID 不是授权，并且模糊性背后仍然需要访问检查
在公共 API 中用 UUID 替换顺序 ID 操作起来很简单，并且不需要系统之间进行复杂的协调。将 UUID 列添加到订单表中，为每个新订单生成一个列，在响应中公开 UUID 并逐渐弃用数字键。您的内部系统可以继续使用整数主键以提高性能和简单性；仅公共接口发生变化。旧的顺序 ID 保留在数据库中供您自己参考或审计跟踪，但客户和第三方只能看到 UUID。这种双密钥方法是维护现有索引性能同时向外界公开不透明标识符的最佳实践。
工作示例 - 在内部整数键旁边添加公共 UUID 列并仅公开前者
此方法与实际授权不同，因为 UUID 不是密码，并且模糊性也不是安全控制。拥有 /orders/{their-uuid} 合法访问权限的客户应该能够查看它，但 /orders/{someone-elses-uuid} 仍必须被您的访问检查拒绝。 UUID 隐藏订单号以防止随意检查，并防止通过枚举进行统计分析，但您的身份验证和授权逻辑仍然由您的应用程序代码负责。保护是分层的：UUID 阻止标识符本身的信息泄漏，并且访问控制强制谁可以对该标识符进行操作。
这不包括什么 - 随机键的索引性能权衡，在单独的帖子中讨论
操作边界很重要，因为 UUID 修复了 ID 本身的信息泄漏，但不会取代访问控制机制。如果客户拥有 API 密钥和足够的权限，他们仍然可以向您的系统发出请求。他们可以访问的范围由您的权限模型和角色定义决定，而不是 ID 格式。 UUID 的好处纯粹在于，标识符会停止向任何可以观察到它的人广播数量、序列和生长数据。精心设计的系统将 UUID 不透明度与对 API 的每个请求进行显式访问控制检查相结合。
要点：将公共引用与内部密钥分开 - ToolAcre 生成器为公共端提供 CSPRNG 支持的 UUID
实际的迁移可以通过逐渐支持两种格式来避免出现问题。如果您对端点进行版本控制，v1 API 可以继续返回整数 ID，而 v2 返回 UUID。客户按照自己的节奏进行过渡，无需协调切换。您的内部数据库查询保持不变：它们仍然按整数 id 进行过滤，因为您的索引是基于该列构建的，并且您的外键引用它。仅返回给客户端的数据发生变化。 ToolAcre UUID 生成器生成您将使用的版本-4 格式；每个输出都是正确的 RFC 9562 UUID 准备用于存储、部署和逐步迁移场景。