エラーを解決できるように、サーバー エラーをキャプチャして管理者に報告する Web アプリケーションがあります。これらのエラーは、デーモンなどの下位レベルで発生した結果です。Webレイヤーの近くにはありません。場合によっては、失敗した SQL ステートメントがエラー ページにバブル アップし、データベース スキーマが露出することがあります。
レポート ページの URI と表示されるエラーとの間に相関関係はありません。私の理解が正しければ、インジェクション用の Web パスがないため、SQL インジェクションの問題は回避されていると思いますが、確認したいと思います。
これらのレポートにアクセスできるユーザーは、サーバー自体にログインして問題のデータベースにアクセスすることもできるため、スキーマが何であるかを本当に知りたい場合は、それを表示する方法があります。
このシナリオで考慮すべきセキュリティ リスクはありますか?
エラー メッセージを中央の場所 (データベースの場合もあります) に記録し、機密情報が共有されないようにするために、ユーザーに表示されるメッセージをサニタイズするルーチンを用意することは、受け入れられている方法だと思います。
悪意のある人物が、SQL インジェクション攻撃やサーバー拒否攻撃などの悪意のある目的でシステムに関する知識を使用する可能性があります。
まず、あなたの質問に答えます。
セキュリティリスクは常に存在します。攻撃者にとって無駄なデータはありません。プレート上の特定の攻撃シナリオでサービスを提供できない場合でも、リスクがないという意味ではありません。
次に、Web フロントにシステム エラー メッセージを表示するというアイデアについて。
他の人がすでに述べたように、それは一般的に非常に悪い考えです。罪のないユーザーは、これらの技術的な詳細を表示する必要はなく、一般化されたエラー ページのみを表示する必要があります。それらの詳細が Web 訪問者に公開されるのはバグです。バグは直したほうがいい。バグを修正することは、Stack Overflow でこのバグが重大かどうかを尋ねるよりもはるかに優れたシナリオです。