API架构-混淆/映射/加密id's
本文关键字：id 映射 架构 混淆 API 加密 | 更新日期: 2023-09-27 18:11:16
我正在为我的公司开发一个RESTful API，但是有几个人对实体id的暴露有一些问题，我可以肯定地看到这是一个关于保护我们的数据的问题。
我的数据是有作用域的，这意味着你首先不能看到不属于你的数据。
我使用Web API和EF6。你们在这个问题上做了什么?这是一个问题吗(为什么/为什么不是)?
如果这是一个问题;
- 我加密或以其他方式混淆id吗?
- 我内部映射到不同的id吗?有什么好的框架吗?
- 我添加一个列到我所有的表与uid和暴露，而不是吗?
在这种方式下，什么被认为是"良好实践"或"安全"?
这个答案的编辑似乎是一个很好的解决方案，但我仍然想看看什么是被认为是好的/坏的/伟大的，也许还有其他解决这个"问题"的方法
不是一个问题，根据这个，我可以看到为什么它不应该是一个问题，只要
- 数据安全范围
"我是否加密或以其他方式混淆id ?"
如果你必须这样做，那么你可能不应该返回它们。
"我是否在内部映射到不同的id ?有什么好的框架吗?
这似乎会给你的应用程序增加高度的复杂性。
"我是否应该在所有表中添加一个带有uid的列并公开它?"
在暴露id时要记住的是，如果你有特定的权限来查看端点:/api/user/1的内容，那么阻止你"走"url并将其更改为/api/user/2以查看其他人的数据。你可以做的一件事是使用Guids作为id来防止遍历url，但一般来说，如果你不需要返回id，那就不要返回。如果你必须返回任何敏感数据，那么它应该总是通过SSL。