1. 题目与使用场景
产品需要让用户分享发票、文件或一次性操作。链接本身携带访问能力，服务端不必先识别登录账户。面试重点是判断这种设计何时合理，以及如何面对链接被复制、记录或转发的现实风险。
2. 面试官考察点
- 能否区分能力 URL、登录会话和 OAuth bearer token 的信任模型。
- 是否把 URL 泄露路径纳入威胁模型：日志、历史记录、分析系统、Referer 和截图。
- 是否设计短时效、最小权限、单次使用或绑定受众的令牌。
- 是否提供按链接撤销、批量撤销和审计能力，而不是只能轮换全局密钥。
W3C 的能力 URL指南强调，泄露后必须能撤销原先授予的权限。OWASP 明确建议不要把密码、API key 或安全令牌放在 URL 中；因此使用能力 URL 必须有清晰的风险边界和补偿控制。
3. 回答前需要澄清的问题
- 资源是公开、低敏感，还是包含个人、财务或合规数据？
- 访问者是否必须登录，链接是否需要跨组织转发？
- 访问是一次性下载、限定时间窗口，还是长期协作？
- 泄露后需要撤销单条链接、某个用户，还是整个资源？
4. 30 秒回答框架
用“适用性—令牌—泄露—撤销—替代方案”回答：
我只把能力 URL 用于低频、可审计且允许持有者访问的资源，并把令牌限制到单个资源和短时间窗口。令牌必须高熵、不可猜测，服务端只存哈希并记录创建、使用和撤销状态；同时设置 Referrer-Policy: no-referrer，避免把它放入日志或第三方分析。敏感资源改用登录授权，能力 URL 只作为一次性邀请或下载凭证。
5. 分步骤深入解答
第一步：选择合适的信任模型
能力 URL 是“持有链接即拥有权限”，不是证明某个账户身份。它适合分享低敏感资源、一次性下载或无需注册的邀请；不适合需要细粒度成员权限、长期审计或强身份保证的操作。若需要 OAuth bearer token，应优先使用 Authorization 请求头；RFC 6750 将 URI 查询参数列为可用但风险更高的传递方式。
第二步：缩小令牌的能力
令牌至少绑定资源 ID、动作和受众。设置短过期时间、单次使用标记和速率限制；对可转发场景可增加收件人确认或登录后再兑换。令牌使用加密随机数生成，数据库保存哈希，避免数据库泄露直接变成可用凭证。
第三步：控制 URL 泄露面
OWASP 提醒，URL 会进入服务器日志、浏览器历史和代理记录。落地页收到令牌后应尽快通过安全请求交换为短期会话，并清理地址栏；设置严格的 Referer 策略，不把令牌发给第三方资源。邮件、截图和聊天工具仍可能暴露链接，因此不要把长期高权限放进去。
第四步：实现精确撤销与审计
为每个令牌记录创建者、资源、动作、过期时间、最后使用时间和撤销时间。撤销检查应在每次兑换或下载前执行；单条链接撤销不能依赖轮换全局密钥。审计日志记录成功、失败、重复使用和撤销原因，帮助识别泄露与滥用。
6. 高质量示范回答
我会先判断资源敏感度和访问生命周期。公开手册不需要能力 URL；一份供外部审阅的低敏感发票可以使用，但高敏感财务报表应要求登录和组织权限。
>
对可用场景，我生成至少 128 位的随机令牌，并让它只对应一个资源、一个动作和一个 24 小时窗口。数据库只保存令牌哈希、状态和审计字段；兑换成功后立即标记使用，下载接口每次都检查过期和撤销状态。响应设置 Referrer-Policy: no-referrer，兑换后把令牌从地址栏移除，页面不加载会向第三方发送 Referer 的资源。
>
用户可以撤销单条链接，管理员可以按资源批量撤销；撤销和重复使用都会写入审计日志。若业务后来需要长期协作，我会迁移到登录授权和成员权限，而不是把能力 URL 延长为永久 bearer token。这样既保留分享便利，也把泄露影响限制在单个资源和有限时间内。
7. 常见错误
- 把“链接很长”当成安全性，忽略日志、历史记录和转发泄露。
- 使用可预测的资源 ID 或自增 token。
- 把长期、高权限 bearer token 放在查询参数中。
- 只有全局密钥轮换，没有单条链接撤销。
- 令牌兑换后仍让它留在地址栏，并加载第三方图片或分析脚本。
8. 追问及应对
追问一：为什么数据库只保存令牌哈希？
令牌是持有者凭证，数据库读权限一旦泄露，明文令牌会立即可用。保存哈希后，服务端可以对提交值做同样哈希比对，降低静态数据泄露影响。
追问二：单次使用会不会导致用户刷新失败？
把一次性令牌用于兑换短期会话，页面刷新使用会话而不是重复兑换原链接；若兑换成功但响应丢失，可提供受限的幂等兑换结果，而不重新开放长期能力。
追问三：何时应完全放弃能力 URL？
当资源高敏感、需要持续成员管理、必须证明访问者身份，或组织要求集中撤销与审计时，使用登录授权和服务端权限模型更合适。