我被告知我不應該直接在Web應用程序的HTML代碼中使用數據庫ID。我應該從我的用戶混淆數據庫ID嗎？
目前我使用的東西如錶行ID（的TableRow-454，其中454是在DB的行的ID），這些ID在隱藏的或製成在網址選擇字段。 （我不是指一個網頁，他們是####上告訴人們視覺。）
我給出的建議是用一些數學從用戶混淆ID。我認爲這隻會讓事情變得更加複雜，並增加不必要的複雜性。但我可以看到一些很好的理由，使得從HTML中確定數據庫ID變得更加困難。
您是否混淆了用戶的ID？或者你在意嗎？
不，你只是爲自己做額外的工作。
只要你做的足夠的測試，在這裏改變的ID或存在不會給用戶訪問的東西，他們不應該那麼你沒事具有標識可見。
在某些情況下，隱藏它們或使用非連續數字，或者可能不從零開始計數。例如，如果有人拿到訂單號碼3，他們可能開始提問...
是的，你可能應該。
如果用戶惡意更改這些ID，沒有你的代碼檢查，以確保他們隨後請求數據仍是他們被允許看到的數據嗎？
隱藏標識比手動進行驗證更容易。
編輯，清晰此時：
如果顯示到屏幕上一個列表與ID的1到20，這是很容易驗證的反應是1和20之間。如果您要顯示實際的ID屏幕，則需要花費內存緩存ID，或者需要進行另一次數據庫調用/更長的查詢，以確保它們不會向您提供錯誤的數據。
如果您使用代理ID，我認爲這變得更容易。
您不需要驗證「遍佈全球」，以確保應用程序安全。只要您首先驗證服務器上的數據，那麼用戶是否更改ID並不重要。 – David 2009-11-04 19:28:12
我同意「是」，但是如果服務器已經盲目地拿到了一個ID，那麼它已經被破壞了。 '沒有說。 – 2009-11-04 19:33:05
如果您不希望用戶更改任何內容，請不要讓他使用瀏覽器。換句話說，**一如既往地不信任客戶端**，混淆該ID不會改變任何內容。 – 2009-11-04 19:33:06
我不喜歡暴露什麼，談到了數據用戶的內部，但是它通常總是會發生特別是當它涉及創建基於數據源的下拉菜單。我的解決方案是在表上使用不同的標識規範來消除增量式攻擊，並在可能的情況下加密查詢字符串值。這並非總是可行，因爲.NET中非常流行的MVC URL模式，所以我傾向於使用唯一的列名稱，然後將其規範化爲URL。然後我在數據庫中查找這個值。然而，沒有簡單的方法可以完全解決它。
我要說的是，如果ID有任何意義的用戶，你正在處理一個數據敏感的應用程序，你應該隱藏的ID的價值。更重要的是，我建議您驗證當前用戶是否有權訪問通過URL請求的數據。例如，如果您有像mysite.com/account/view/12這樣的URL，當前用戶是否可以訪問該帳戶ID（即12）。
如果信息是公開的而且不敏感，我會說它不需要隱藏ID值。
你應該對用戶隱藏
爲什麼數據庫ID？這是他們（用戶）不需要關心的實現細節。我是ID 123311122？誰在乎！ （除非，也許我在ICQ上）。例如，看看SO如何最小化（但不會消除）暴露。
在備註上，使用可預測的ID也是另一種攻擊的載體，通過默默無聞的安全性，但它仍然是另一種有效的工具。我從來沒有在軟件上工作，但這一直是個問題。這就是說，如果你的框架沒有提供處理「隱藏ID」或提供乾淨映射的手段，那麼它可能根本不值得它切換。
我會說，它一般是OK，但也有一些陷阱：
如果您的號碼是連續的你開闢爲「猜謎遊戲」（例如用戶改變細節ID = 4511？詳情？id = 4512查看別人的詳細信息）。爲了抵消這個，你首先需要適當的安全。在某些情況下，這還不夠，因爲揭示信息存在本身可能是一個問題。以Youtube爲例，他們使用更多的id：s來避免機器人屏幕刮花。
如果您對id的性質做出假設，您可能會遇到麻煩（即，如果您直接在GUI中操作id：s或對基於id的項目進行排序）。這可能是一個令人討厭的驚喜，一旦你需要負載平衡你的數據庫，並最終與單獨的ID範圍。
ID複用。例如，MySql：InnoDB引擎會在重新啓動時重置序列（以最新的最大值）。如果你刪除了，這可能會讓你很難受。
但是，所有這些陷阱也適用於自定義id：s，但可能是這些人來自哪裏。我眼中最靈活的解決方案是GUID：s，因爲您可以在任何地方生成它們，並且不會遇到上述任何問題。雖然它們很難爲人類閱讀，所以這是一個折衷。
我建議你使用友好的名字。它更現代，更語義。另外，創建鏈接時看起來更好。
例如，考慮mysite/products.aspx？id = 25 vs mysite/products/ferrari。後者更清潔，更易於記憶（針對用戶）等等。
如果您當前正在隱藏字段中使用ID，請嘗試使用會話來存儲這些值。如果您僅在您提到的錶行ID中使用它們，我認爲隱藏它們不值得花時間。
2件事：儘管使用乾淨的URL，但當您擁有大量產品時（例如），它會失敗。像SO這樣的東西會失敗，因爲問題標題不是唯一的，因此已經包含了ID和問題標題。關於在會話中存儲ID ...這很好，除了一件事：標籤:( – 2009-11-05 02:36:22
是的，我必須同意你的意見 但是對於一個小型網站，標題是獨特的，它可以工作好。 – Venemo 2009-11-05 08:39:57
IMO：不，你不應該混淆身份證。如果您的應用程序擔心安全問題，則無論如何您都需要其他安全措施。默默無聞的安全是不夠的，它只是給你一種虛假的安全感。
順便說一句，如果你做的只是一個小數學，那麼其他ID也可能被掩蓋 - 仍然可以預測。在很多情況下，壞人並不關心他打入哪個帳戶，只要它不是他自己的;-)
ID:s in URI:s are a part of a good UI如果你希望你的用戶能夠走上這條路。所有URI：s都是公共的，它取決於響應頁面來處理請求並基於某種認證進行渲染。
交易和其他敏感材料可以很容易地用鹽醃+哈希串隱藏並存儲在另一列在你的數據庫，如果你想要，但如果你還沒有驗證用戶輸入（在web編程明確可能是「通過URI導航」），你錯過了這一點。
作爲Greg answered，訂單數量可能不應該是低的，但是這方面的信息處理的責任不應該在網頁中，但該組織的/你的既定值內騙（即你仍然會打印出爲什麼要將它隱藏在第一位？）
由於網絡和現在一樣透明，所以很難找到它的另一種用途，除了它的使用方式縮短了URI：s，即Youtube的視頻頁面和無數的URI縮短服務。
作爲向公衆發佈一個ID的一個例子，請看這篇文章的網址。我試過https://stackoverflow.com/questions/1，但看起來它已被刪除。你必須去While applying opacity to a form should we use a decimal or double value?找到「第一」序數問題; ）
......沒有傷害，只是對另一篇文章的引用。 「
」我被告知我不應該直接在Web應用程序的HTML代碼中使用數據庫ID ... 您是否對用戶的ID進行了混淆？
用戶期望面臨的數據可以鏈接到他們在工作中處理的現實世界。
「數據庫ID」應該是用戶界面的一部分，只是這些ID也是用戶實際工作情況的一部分。如果不是，那麼應用程序確實應該完全屏蔽用戶。
做這個屏蔽確實等於「更多的工作」，但這是完全不相關的。不做這種屏蔽意味着給用戶提供一個應用程序，這對他來說更難以處理，這最終會導致用戶自己每天都在做更多的工作。
如果您決定在隱藏字段中進行防篡改行標識，您可以查看Steve Sanderson的asp.net mvc書籍，其中他爲此提供了一個HMAC（散列消息認證代碼）Utility類。當然是.NET，但你可以明白。你可以在谷歌圖書上看到它（桑德森寫過關於我讀過的最好的編程書籍）。
當我在html中放置行標識並且業務模型表示用戶應該有權訪問某些行（例如他/她已插入的行）時，我可能會設計一個db表以包含用戶標識列並將其包含在任何數據庫操作中（僞代碼：where @rowID = table.rowID AND @userID = table.userID）。這樣，如果另一個用戶用戶在隱藏字段中隱藏了rowID，那麼數據庫操作不會讓他們看到另一個用戶的數據，因爲用戶ID不匹配。當然，這種方法假設你使用某種類型的身份驗證，但它也沒有被黑客入侵。
我很好奇，看看我們的兩個反應中哪一個獲得更多的牽引力。 – 2009-11-04 19:27:04
是的，它會很有趣 – Greg 2009-11-04 19:28:23
+1。另外，如果您擔心順序ID，則可以始終使用GUID。 – David 2009-11-04 19:29:28