通过验证 URL 中类似 token 的字段 (如 https://domain.com/[TOKEN]/file.txt) 能在多大程度上避免未经授权的访问？

[dLvsYgJ8fiP8TGYU]

假设：

• 服务器可信
• 中间链路无 MITM 攻击
• token 长度未知

潜在攻击者即使知道了在路径的这一处需要输入 token，是否只能通过枚举来尝试访问 file.txt ？

如果连续两层路径都是 token，如 https://domain.com/[TOKEN1]/[TOKEN2]/file.txt ，是否能够显著提升枚举所需的时间？

潜在攻击者是否可通过某种方式直接查看目录 tree，然后绕过 token 机制直接访问文件？

在我的理解里（不知道是否正确），你创建一个名称很长且随机的文件夹，（对于访问者来说）就等效于需要输入 token 才能访问里面的文件了；如果路径输入不对就会 404

[Jat001]

只要你没做任何映射，没开列出目录的功能，没在任何地方泄露这个地址，那么攻击者除了穷举没有别的办法得知这个地址了

[Jat001]

不过更安全的办法是 url 里带个会过期的 token，中间做个鉴权，直接访问文件一但路径泄露就没办法了

[LokiSharp]

header 里加 token 不更好么

[codehz]

列目录的前提是真的存在有目录（
url 不必真的映射到文件系统上，完全可以只是作为路由参数而已，即使真的映射到文件系统，那也得服务端提供列目录的功能。。。

[gstqc]

1. token 需要管理，比如创建、销毁、验证。建议用成熟的方案
2. 代码有漏洞或者服务器漏洞可能能绕过 token 验证

[chendy]

攻击者的目的是什么？遍历文件？绕过权限控制访问文件？
为什么不考虑常规的权限机制呢？

[ch2]

cdn 鉴权了解一下，你的这种例子只是一种鉴权方法

[love]

加个标准 http 密码保护就行,还不用担心地址泄露到搜索引擎什么的

[killergun]

token 有过期且一次性访问

[THESDZ]

oss 对象存储的签名机制