我让另一位开发人员提出了将所有参数组合并加密/隐藏到php页面的可能性，作为一种安全措施，防止通过特制的url进行操作，并防止数据库内部知情（例如，知道数据库中特定条目的id）。
换句话说，将存在一个加密的blob，而不是像id这样的单个或多个公共查询参数，该blob将在服务器端解密，并在创建链接时重新加密。
这种方法有问题吗？是否有实质性的优势使其值得？这种方法在野外使用效果好吗？
您应该设计系统以防止未经授权的访问。模糊（不可能对客户端生成的数据进行有用的加密）是不值得防御的。
相反，与其给用户一个数据库ID，不如给他们一个ID的哈希（也许还有一个会话种子）。哈希的128位以上搜索空间和（对于合理的数据库大小）低冲突概率将是更好的方法。您也可以在服务器上加密客户端从不需要处理的值的ID（使用种子），但要确保它具有与我提到的哈希相同的属性——即搜索空间与可能的值空间相比非常大。
如果你想防止用户干扰GET参数，我建议如下：
将隐藏表单添加到所有页面。点击页面上的任何位置，都会在表单中填写一些数据，并通过POST/SSL安全地提交。在提交详细信息的同时，传递您希望将用户引导到的URL。
在服务器端，收集参数，将它们全局地或附加到目标URL的某种标识符下放入会话。发回重定向。这样，若用户刷新页面，就不会对POST数据喋喋不休。此外，如果他开始在应用程序中来回乱转，请终止会话缓存并将其发送到起始页。
我在一些网上银行软件中看到过这种技术。另一个好处是用户无法打开新窗口。
在我看来，它可以增加一定程度的安全性，但会严重改变开发方法，并给您更多的工作。我自己从未使用过这种方法，我认为只要你有一个合适的ORM系统，无论你的开发人员会写什么样的代码，在任何情况下都不会让用户a访问用户B的数据，ID就可以安全地传递。
在某些情况下，这种类型的URL加密（或Obsfuncating）可能很有用。假设您在应用程序中构建了一个非常强大的安全性，并且所有主机都是安全可靠的。
现在，如果您的操作人员碰巧是外部人员，并且您不希望他们通过动态更改日志级别来了解/查看这些敏感数据（ID），那么最好按需通过单个模块对其进行加密和解密。
作为一种常规做法，不应在URL参数中传递任何敏感数据，还应注意不要在更高级别上记录这些数据。