主キーの公開（特に予測可能な場合）は、Insecure DirectObjectReferenceと呼ばれる脆弱性です。
次のようなURL（または他のクライアント提供のパラメータ）を使用する：
http://www.domain.com/myaccount?userid=12
エンドユーザーに、これらの変数をいじって、好きなデータを渡す機会を与えます。この脆弱性を軽減するための対策は、代わりに間接的なオブジェクト参照を作成することです。これは大きな変化のように聞こえるかもしれませんが、必ずしもそうである必要はありません。すべてのテーブルなどを再入力する必要はありません。間接参照マップを使用してデータを巧みに処理するだけで、キーを再生成できます。
これを考慮してください：あなたはあなたのサイトで購入をしているユーザーを持っています。そして、支払う時間になると、あなたが「登録」している彼らのクレジットカード番号のドロップダウンが表示されます。ドロップダウンのコードを見ると、クレジットカード番号がキー8055、9044、および10099に関連付けられていることがわかります。
ユーザーはこれを見て、主キーの自動インクリメントによく似ていると思うかもしれません（ユーザーはおそらく正しいでしょう）。そこで彼は、他の誰かのカードで支払うことができるかどうかを確認するために、他のキーを試し始めます。
技術的には、選択したカードがユーザーのアカウントの一部であり、ユーザーがそれを使用できるようにするコードをサーバー側に配置する必要があります。これは不自然な例です。今のところ、これは当てはまらないか、これはおそらくそのようなサーバー側の制御がない別のタイプのフォームであると想定します。
では、エンドユーザーが使用できないキーを選択できないようにするにはどうすればよいでしょうか。
DB内のレコードへの直接参照を表示する代わりに、間接参照を提供します。
DBキーをドロップダウンに配置する代わりに、サーバー上に配列を作成し、それをユーザーのセッションに詰め込みます。
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
ドロップダウンで、カードが保存されている配列のインデックスへの参照を提供します。したがって、エンドユーザーがソースを表示する場合、実際のキーを表示する代わりに、値0、1、および2を表示します。
フォームが送信されると、これらの値の1つが渡されます。次に、ユーザーのセッションから配列を取得し、インデックスを使用して値を取得します。実際のキーがサーバーを離れたことはありません。
また、ユーザーは必要に応じて1日中さまざまな値を渡すことができますが、サーバー側のアクセス制御が設定されているかどうかに関係なく、自分のカード以外の結果を取得することは決してありません。
ただし、渡されたインデックスを使用して値を取得する場合、ユーザーがそれを台無しにすると、いくつかの例外（ArrayOutOfBounds、InvalidIndexなど）が発生する可能性があることに注意してください。したがって、それらをtry / catchでラップして、これらのエラーを抑制し、失敗をログに記録してクラッキングの試みを探すことができるようにします。
これがお役に立てば幸いです。
安全でない直接オブジェクト参照の詳細については、OWASPトップ10を確認してください。これはリスク番号A4です。 https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References