データベースID（URLなど）を公開することはセキュリティ上のリスクであると聞きましたが、その理由を理解するのに苦労しています。
なぜリスクなのか、なぜそうでないのかについての意見やリンクはありますか？
編集：もちろん、アクセスはスコープされています。たとえば、リソースfoo?id=123が表示されない場合、エラーページが表示されます。それ以外の場合、URL自体は秘密にする必要があります。
編集：URLが秘密である場合、おそらく、有効期間が限定された生成されたトークンが含まれます。たとえば、1時間有効で、一度しか使用できません。
編集（数か月後）：私が現在これを好む方法は、IDにUUIDSを使用して公開することです。IDとして（通常は一部のDBでのパフォーマンスのために）連続番号を使用している場合、各エントリのUUIDトークンを代替キーとして生成し、それを公開します。
回答:
適切な条件を前提として、識別子を公開することはセキュリティリスクではありません。また、実際には、識別子を公開せずにWebアプリケーションを設計することは非常に負担になります。
従うべきいくつかの良いルールはここにあります：
データセキュリティリスクではありませんが、データサイズと速度の両方を公開するため、これは完全にビジネスインテリジェンスのセキュリティリスクです。私は企業がこれによって害を受けることを見て、このアンチパターンについて深く書いています。ビジネスではなく、単に実験を構築しているのでない限り、私はあなたのプライベートIDを公衆の目に触れないようにすることを強くお勧めします。https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e
IDの意味によって異なります。
競争上の理由で、メンバーの数を公開したくないが、シーケンシャルIDを使用することで、いずれにせよURLでそれを明らかにしているサイトを考えてみましょう：http : //some.domain.name/user?id=3933
一方、代わりにユーザーのログイン名を使用した場合：http : //some.domain.name/user?id=someユーザーは、ユーザーがまだ知らないことは何も開示していません。
一般的な考え方は次のとおりです。「アプリの内部動作に関する情報は誰にも公開しないでください。」
データベースIDの公開は、一部の情報の公開と見なされます。
これの理由は、ハッカーがアプリの内部の仕組みに関する情報を使用してあなたを攻撃したり、ユーザーがURLを変更して、自分が見るはずのないデータベースにアクセスしたりできることです。
データベースIDにはGUIDを使用します。それらを漏らすことはずっと危険ではありません。
dbで整数IDを使用している場合、qs変数を変更することで、ユーザーが見るべきではないデータを簡単に見られるようにすることができます。
たとえば、ユーザーはこのqsのidパラメータを簡単に変更して、http：// someurl？id = 1にすべきでないデータを表示/変更することができます。
データベースIDをクライアントに送信すると、強制されます両方のケースで、セキュリティをチェックします。WebセッションでIDを保持する場合は、それを実行するかどうかを選択できます。つまり、処理が少なくなる可能性があります。
あなたは常にあなたのアクセス制御に物事を委任しようとしています;）これはかもしれませんあなたのアプリケーションのケースんが、私のキャリア全体でそのような一貫したバックエンドシステムを見たことはありません。それらのほとんどは、Web以外での使用向けに設計されたセキュリティモデルを備えており、一部には死後に追加された追加の役割があり、それらの一部はコアセキュリティモデルの外部に組み込まれています（役割が異なる運用コンテキストで追加されたため、ウェブの前）。
したがって、合成セッションのローカルIDを使用します。これは、できる限り多くのことを隠すためです。
非整数キーフィールドの問題もあります。これは、列挙値などの場合に当てはまる可能性があります。そのデータをサニタイズしてみることができますが、小さなボビードロップテーブルのようになる可能性があります。