为什么数据库的主键不应该显示在 html 代码中，例如在选择字段中？
我在任何地方读到选择框中的值（或 html 代码中的其他任何内容）不应该是数据库表的主键。例如：
<select>
<option value="1">Value 1</option>
<option value="2">Value 2</option>
</select>
在数据库中存在以这些值作为主键（1,2,3,....）的查找表。因此，我存储在引用该查找表的表中的选择框的数据是像 1、2、3.... 这样的数字（作为选项字段的值）。 由于安全原因，我读到最好不要在 html 和 key 中使用相同的值，但这有什么问题呢？我不明白为什么这应该是一个安全原因？
anywhere I read that values in select boxes (or anything else in the html code) should not be the primary key of the database table. For example:
<select>
<option value="1">Value 1</option>
<option value="2">Value 2</option>
</select>
In the database there are lookup tables with these values as primary key (1, 2, 3,....). So the data from the select box I store in a table which references this lookup table is a number like 1, 2, 3.... (as the value of the options fields).
I read to better not use the same values in html and as key due to security reasons, but what's the matter with that? I don't understand why this should be a security reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
听起来像 security-through-obscurity，对我来说根本没有安全性。
数据库中一个好的主键纯粹是为了系统中的唯一性，不应该与数据的含义相关。如果主键与数据相关（比如人们的社会安全号码，诸如此类的东西），那么在暴露密钥时就会遇到安全问题，因为它们暴露的信息可能会被泄露。 被恶意使用。在这种情况下，虽然您可能认为从技术角度来看最好的方法可能是更改应用程序以停止使用这些有意义的键，但将键映射到其他一些无意义的键来克服可能是一种更容易接受的方法的问题。
我想到的另一种情况是，暴露密钥可能会被解释为安全问题，即应用程序/数据层中的可写数据的身份验证和授权不充分，从而允许了解这些密钥的人干扰应用程序/数据层中的数据。应用。同样，保护系统安全是更好的方法。
除了安全性之外，如果密钥确实能够识别正在交互的数据并且您的应用程序在生成页面时正在查找密钥，我想不出具体的问题。
Sounds like security-through-obscurity, aka no security at all to me.
A good primary key in a database is purely for uniqueness in the system and shouldn't be related to the meaning of the data. If the primary key was related to the data (say people's social security numbers, stuff like that) then you've got a security issue in exposing the keys, as they are exposing information that could be used maliciously. In that case, whilst you could argue that the best approach from a technical point of view might be to change the application to stop it using those meaningful keys, it may be a more palatable approach to map the keys to some other meaningless key to overcome the issue.
Another scenario that springs to mind where exposing the keys might be interpreted as a security issue is where inadequate authentication and authorisation is in place for writable data in your application/data layer, allowing someone with knowledge of those keys to interfere with the data in the application. Again, securing the system is the better approach.
Aside from security, I can't think of a specific issue if the keys really do identify the data being interacted with and your application is looking up the keys when it generates the page.
我会关心如何处理来自 URL 的信息。如果我使用 value="does_this_break_the_code" 或 value="can_I_read_secret_info" 发布内容会发生什么
I would be concerned about how the information is processed from the URL. What happens if I posted content using value="does_this_break_the_code" or value="can_I_read_secret_info"
在 URL 或 HTML 或应用程序代码中使用代理键时应谨慎行事。一般来说，我不会对钥匙说同样的话。
代理键不应具有业务意义，也不应具有应用程序代码或外部流程的依赖性。这通常是一个重要的考虑因素，例如，如果由于数据库设计的发展或数据集的合并而需要更改键值。通过在代码或 URL 中使用代理键作为“幻数”，您可能会损害代理键的有用性。此外，代理键对于用户（可能还有开发人员）来说不太方便，因为这些值对他们来说毫无意义，因此比使用自然键可读性较差。
我建议您在 URL 和持久代码中使用自然键。将代理键保留在数据库内部，这是它们应该在的位置。
It would be wise to exercise caution in using surrogate keys in URLs or in HTML or application code. I wouldn't say the same thing about keys in general.
A surrogate key is not supposed to have business meaning or to have dependencies in application code or external processes. That's often an important consideration for example if key values need to change as a result of the database design evolving or data sets being merged. By using surrogate keys as "magic numbers" in code or in URLs you could compromise the very thing that makes surrogate keys useful. Also surrogate keys are much less convenient to users (and possibly developers) because the values are meaningless to them and therefore less readable than using a natural key.
I suggest you use natural keys in your URLs and persistent code. Keep surrogate keys internal to the database, which is where they are supposed to be.
主键应用作数据库中每个项目的唯一标识符，很可能它不是零件号或与实际项目相关的任何内容。一般来说，PK 没有任何意义，在语义世界中，一切都应该有意义。如果有更好的唯一标识符，请务必使用它，因为您的 PK 除了对数据库之外没有任何帮助。
假设您有一个汽车数据库，所有汽车都有一个称为 VIN（车辆识别号）的唯一标识符，VIN 中编码了有关每辆特定汽车的一系列信息，直至制造该汽车的工厂。 VIN 仅识别一辆特定的汽车。物品上的 PK 可以是任何东西，汽车从数据库中删除，现在 PK 不存在，但 VIN 仍然存在于某处。这是一个比 PK 更好的唯一 ID，因此这可能应该显示给用户。
Primary keys should be used as a unique identifier for each item in the DB, chances are it isn't a part number or anything that relates to the actual item. Generally speaking the PK doesn't MEAN anything, and in the world of semantics, everything should mean something. If there is a better unique identifier, by all means use it, because your PK isn't helpful to anything but your database.
Say you have a database of cars, all cars have a unique identifier called a VIN (Vehicle Identification Number) in the VIN is encoded a bunch of info about each specific car down to the plant that made it. The VIN only identifies that one specific car. the PK on the item could be anything, the car gets dropped from the DB, now the PK doesn't exist, but that VIN is still out there somewhere. It's a much better unique ID than the PK, so that's what should probably be displayed to the users.