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

问题描述

我听说有几个人说你不应该将你的内部ID暴露在外面（例如auto_increment'ng主键）。

有些人建议您使用某种uuid列，而不是用于查找。

我想知道真的为什么会被建议，如果它是真正重要的。

而不是使用uuid基本上只是混淆了id。重点是什么？我唯一可以想到的是，auto_incrementing整数显然指出了我的db对象的顺序。外部用户是否知道有一件事是在之前/之后创建的？

或者纯粹是混淆ids将阻止在不同操作上猜特定的对象？

这是否是设计外部面向API时应考虑的问题？

解决方案

很好的答案，我将再次提出一个原因，为什么你不想公开你内部的自动递增的ID。

作为一个有竞争力的公司，我可以轻松地测量多少新用户/订单/等你每周/天/小时。我只需要创建一个用户和/或订单，并从上次获得的新ID中扣除。

所以不仅出于安全原因，这也是商业原因。

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).

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.

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?

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

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

解决方案

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屋！