假设我有一个存储信用卡信息的网站，并且在该网站上我有一个页面，用户可以在其中编辑/删除他们的信用卡信息。
为了这个例子，假设 HTML 看起来像这样：
<div>
xxxx-xxxx-xxxx-1234
<span data-ccid="6E3E8D62-9F94-4FEE-BD1D-FDF87E1A3C50">Delete</span>
</div>
并且单击Delete文本将调用删除ID为的信用卡data-ccid。
假设某人不可能预测系统中的另一个信用卡 ID 并发出删除除他们自己以外的卡的电话，这是否安全？
让我们假设您正在使用足以满足 PCI DSS 的标记化/加密技术。
不，我们正在研究一个抽象问题，即有人可以预测一个值。风险因素是，如果可以猜测该值或遵循已知模式，则可以随意删除。
GUID 的问题无关紧要，因为攻击向量仍然是蛮力攻击。虽然了解用于创建唯一 id 的模式或算法当然可以帮助减少更多受字典限制的攻击的可能性，但提前了解 id 并不是不加选择地删除记录所必需的。
您可以通过实施额外的控制来解决问题。首先，如果这是在数据库中，则您有足够的日志记录和事务。
在执行删除的过程中，应该有额外的控制。让我们从用户端开始：如果记录与用户相关联，则只有用户应该具有删除他/她自己的记录的能力。如果用户未通过身份验证或不拥有记录，则不允许删除过程继续进行。用户是否需要提供特殊授权？是否在数据库或会话中设置了另一个变量以允许删除（例如，他们需要在操作通过之前进行授权？）如果有足够的风险，您可以实现带外确认，例如发送一个短信或电子邮件确认是可以接受的。在这种情况下，如果用户故意删除他们自己的信用卡记录，因为他们可以稍后再次输入，这可能是低风险的。
如果您有强大的身份验证、授权和事务控制，它将限制不加选择地删除值的能力，即使它们是已知的。
作为额外的预防措施，您可能希望实施启发式和攻击检测算法。例如，限制每天从同一 IP 地址删除的次数。考虑到正常的删除模式等，如果在给定的一天内删除过多，则回滚事务。
从您的描述中听起来，正在执行一个简单的 POST 命令，我将确保仅在存在 TLS/SSL、用户已通过身份验证、请求中有 CSRF 令牌等情况下才会发生这种情况。我将确保记录所有删除并且可以回滚。由于删除不会导致曝光，您还可以依靠对用户的事后通知，“我们确认您已删除存档的信用卡。如果您没有这样做，请立即与我们联系”等。
听起来您所说的风险是通常所说的跨站点请求伪造（“CSRF”）。有一些常见且经过充分测试的机制可以解决此类漏洞，甚至通常可以简单地将预制库包含到代码中（许多框架都内置了 CSRF 保护！）。
将 CSRF 保护添加到应用程序后，与记录关联的 ID无关紧要；你可以像我们其他人一样按顺序编号。
另外，请记住，虽然您已经注意到此特定页面上的潜在漏洞，但您的代码中可能还有许多其他位置适用相同的警告。最好用一个共享的解决方案一次性处理它们，而不是尝试独立清理每个单独的表单。
并回答你原来的问题：不。GUID 只是可能是唯一标识符的一种格式。该 ID 的来源取决于实施。有几种不同的常用机制可用于生成新的 GUID，其中一些是可预测的，而另一些则不太可预测。但它们通常不是加密的随机数。
不，请不要这样做！！如果您的随机化是基于可预测的因素，例如时间（即伪随机），或者存在任何其他类型的错误/信息泄漏，可以找出它。相反，在允许执行此类查询之前，请确保授权用户已通过身份验证。
或者更好的是，不要自己存储信用卡，依靠第三方（如贝宝）代表您进行此类财务处理。