API 设计和安全性:为什么要隐藏内部 ID? [英] API design and security: Why hide internal ids?

问题描述

我听说有些人说你永远不应该将你的内部 ID 暴露给外部世界(例如 auto_increment'ng 主键).

I've heard a few people say that you should never expose your internal ids to the outside world (for instance an auto_increment'ng primary key).

有些人建议使用某种 uuid 列来代替查找.

Some suggest having some sort of uuid column that you use instead for lookups.

我真的想知道为什么会建议这样做，以及它是否真的很重要.

I'm wondering really why this would be suggested and if it's truly important.

改用 uuid 基本上只是混淆了 id.重点是什么?我唯一能想到的是 auto_incrementing 整数显然指出了我的 db 对象的顺序.如果外部用户知道某件事是在另一件事之前/之后创建的，这是否重要?

Using a uuid instead is basically just obfuscating the id. What's the point? The only thing I can think of is that auto_incrementing integers obviously point out the ordering of my db objects. Does it matter if an outside user knows that one thing was created before/after another?

或者纯粹是混淆 id 会阻止对特定对象的不同操作进行猜测"?

Or is it purely that obfuscating the ids would prevent "guessing" at different operations on specific objects?

在设计面向外部的 API 时，这是否也是我应该考虑的问题?

Is this even an issue I should thinking about when designing an external facing API?

推荐答案

很好的答案，我会为您不想公开内部自动递增 ID 的原因添加另一个原因.作为一家有竞争力的公司，我可以轻松地衡量您每周/每天/每小时获得多少新用户/订单/等.我只需要创建一个用户和/或订单，然后从上次获得的 ID 中减去新 ID.
因此，不仅出于安全原因，也是出于商业原因.

Great answers, I'll add another reason to why you don't want to expose your internal auto incremented ID.
As a competitive company I can easily instrument how many new users/orders/etc you get every week/day/hour. I just need to create a user and/or order and subtract the new ID from what I got last time.
So not only for security reasons, it's business reasons as well.

这篇关于API 设计和安全性:为什么要隐藏内部 ID?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！