検証/認証/処理に使用されるすべての ajax 呼び出しを渡す必要がある UserId、tokenId、sessionId などのデータがあります。
そのデータをグローバル JS オブジェクトに保存しました。したがって、ユーザーがページのソースを表示すると、これが表示されます。
私の組織の侵入セキュリティ チームによると、ソースを表示する際に UserId、tokenId、sessionId などの機密データを表示するセキュリティの脅威です。
ソースを表示しても表示されないデータを js/browser に保存する方法は? web 開発会社が userId のようなデータを保存するために使用するさまざまなアプローチは? このデータを Cookie または暗号化で保存すると、頻繁に使用されるため、パフォーマンスが低下します。
tokenId は CRSF トークン ID で、sessionId はセッション ID です。
多くの仮定に基づいてこれに答える必要がありますが、質問を編集してお知らせいただければ、回答を更新します。
とはUserId?
これがユーザーのクリアテキスト ID である場合、システムに危険が及ぶ可能性があります。
たとえば、管理者アカウントに ID があり、悪意のあるユーザーがCookie を に0設定した場合、悪意のあるユーザーは管理者のふりをすることができますか?UserId0
あなたは何を言っていないので、これtokenId以上sessionIdコメントするのは難しいですが、この回答の目的のために、それtokenIdはAnti-CRSF トークンでsessionIdあり、認証セッション ID であると仮定します。
この場合、UserIdCookie 値またはページの非表示フィールドから取得するべきではありません。サーバー側で取得する必要がありsessionId、現在のユーザーが認証したセッションから取得する必要があります。
適切なヘッダーを設定してパブリック キャッシュを無効にしている場合、ソースに表示されるtokenId固有のリスクはありませんが、これらの値が Cookie で既に使用可能な場合は、コードで再度設定する必要はありません。これは、AJAX リクエストが 2 つの方法 (リクエストと Cookie) で値を送信するため、潜在的なビジネス ロジックの欠陥の匂いがします。そのため、すべてのロジックが一貫していることを確認するために、1 つの方法のみを使用していることを確認してください。sessionId
要約すると、セッション データの最も「安全な」場所は、実際には Cookie 内にあります。これは、Cookie メカニズムの外部 (キャッシュされたページのソース内など) にキャッシュされないためです。ただし、 SecureフラグとHTTP Onlyフラグを設定して、これらの Cookie が HTTPS 経由でのみ送信され、DOM 経由では使用できないことを確認してください。