我想创建一个API来获取客户详细信息。
url可以是Gethttps://../customers/｛customerId｝。
我的问题是customerId是敏感的，可以在url中传递它吗？
如果没有，最好的方法是什么？
customerId是信息的敏感部分，这很奇怪。此外，你们并没有分享太多的上下文。我能想到的使其安全的选项我会：
- 将敏感的
customerId替换为要链接到UUID或其他非敏感信息的，然后从UUID查找以找到真正的客户 - 使用POST和https，确保任何敏感信息的安全
第一个问题，customerId真的敏感吗？在某个时刻，您的客户端将把资源的标识符传递给API。即使您对值进行加密，或将其打包到有效负载中作为POST请求，该值仍然可以被检查，并且仍然可以被真正想要访问或更改它的客户端或数据包嗅探器伪造
A： 是的，你可以在url中传递customerId
这是一个标准的期望。事实上，尝试在路由中传递Id可能会违反直觉，如果Id是路由的一部分，则为基于REST的API编码和管理会容易得多。
但有可能
具体的实现将取决于您的运行时和代码框架，但作为一种设计模式可以将重写模块或中间件写入服务器，从而解密加密的查询字符串，然后将响应管道内部重定向到内部或安全路由。通过这种方式，您在标准API处理之间注入了这个安全层，并且不必在每个端点进行任何特殊的破解来解析从客户端传递的Id。
然而
这意味着客户端必须加密或计算要发送到API的值，这意味着现在客户端拥有可以创建令牌的代码，因此对逻辑进行逆向工程并为其他客户创建自己的令牌是一项琐碎的任务。
而不是加密
在我遇到的上一个项目中，这是一个虚荣的问题。我们不希望用户试图通过更改URL中的Id来破解系统，在某些情况下，他们只是不希望用户感觉自己像个数字。。。
因此，在这种情况下，它与真正的安全性或保密性无关，与我所说的"虚荣"无关。
通过这种方式，客户端使用参数调用API上的端点，并返回令牌。我最后确实使用了加密来避免存储原始参数，但关键是API返回一个它知道如何解密的令牌。
您可能熟悉TinyURL服务，这几乎是同一个概念。
我发现用户加密更简单，在这种情况下，服务器同时持有加密和解密密钥，所以我不担心客户端受到感染的人会危及安全，但这并不是一种安全功能。