除非该站点现在对 URL 进行了访问控制（要求您首先进行身份验证 - 证明您的身份 - 然后服务器检查您的身份是否有权查看该 URL），否则不安全。明显的问题包括人们通过这样的网站共享链接（没有编辑域），浏览器在他们的历史记录中记住 URL（在共享的计算机上），或者有人（内部或外部）转储和共享有效 URL 列表。

用于此类安全漏洞的术语是“直接对象引用”，当输入对象的 ID 时，即使您通常无权访问，您也可以访问该对象。问题的唯一真正解决方案是适当的访问控制。仅仅让猜测对象 ID 变得困难并不能解决问题，尽管在短期内它可能会使利用变得更加困难。把秘密放在 URL 中并不能真正解决任何问题。您需要一个依赖实际凭据的系统。

现在，至于枚举：正如评论所指出的，这是一个非常可疑的编码。重复的前缀表明，无论他们在做什么，他们都没有使用安全哈希（或没有正确使用它）。鉴于他们可能试图从 URL 映射回对象标识符，无论如何这可能是一种可逆编码。

使用只有服务器知道的密钥对 URL 查询字符串进行加密会产生难以猜测的链接，尽管根据所使用的加密类型，仍然可能在不知道加密密钥的情况下翻转位并产生新的有效 URL（他们需要添加完整性检查，例如 HMAC 或经过身份验证的加密方案，以防止这种情况发生）。加密本身并不能阻止攻击者篡改密文（以及一些很容易篡改的加密方案）。在任何情况下，这样的系统都依赖于保持秘密的密钥，从而导致单点故障。

使用已知密钥加密查询字符串 - 例如，如果密钥位于该不变的前缀中 - 完全被破坏。弄清楚所使用的加密方案需要一点点（受过教育的）猜测和检查，但可能的系统空间将花费很少的时间来搜索。一旦知道，制作有效的 URL 就很简单了。

做到这一点的最不坏的方法（没有好的方法；对于任何敏感的东西，您只需要使用身份验证和访问控制）是存储合理长度（64 位以上；GUID 经常在这里使用）、加密安全的随机标识符对于数据库中的每一行。然后在将它们转换为 URL 之前，使用服务器端的密钥对其进行加密。这避免了单点故障（没有密钥，随机 ID 无用，反之亦然）破坏整个有效 URL 列表，还意味着您可以执行诸如定期更改 ID 令牌以使这些对象的旧 URL 无效的事情，或更改加密密钥以使所有旧网址。防止对密文进行位翻转是安全的，因为没有办法说“假设这部分是一个数字，然后尝试翻转位以产生另一个有效数字”；位的有效组合在可能的标识符的搜索空间中是不可猜测的一小部分，因为标识符不是连续的并且足够长，以至于只有极小的一部分会被使用。

但是，我必须再次强调：这比仅仅进行适当的身份验证和授权要糟糕得多。如果你这样做了，你可以安全地坚持简单的递增数字标识符，因为猜测下一个值不会让攻击者得到任何东西。