RESTアプリケーションでHTTPステータスコード500を公開する必要がありますか？
私のSpring MVC 3アプリケーションでは、RESTパターンと多くのロジックはHTTPステータスコードに基づいています。たとえば、500はサーバーエラーを定義します。ただし OWASP modsecurity このステータスコードを公開しないように言います。
500ステータスコードが悪い理由がわかりません。 Googleは500を適切に表示します も表示します。
エラー500は、サーバーに内部エラーがあったことを示します。通常、次の2つの可能性のいずれかを意味します。
- どちらかのコンポーネントがダウンしている-了解、エラーが再びアップするとすぐに消えます
- または、例外条件がアプリケーションによって正しく処理されない
エラー500が発生した後は、常にアクションを実行する必要があります。コンポーネントがダウンしている場合は、コンポーネントを修復または再起動する必要があります。例外条件がフィルタリングされなかった場合は、アプリケーションの修正が必要です。
例外的な条件を処理せず、監視と保守が不十分なアプリケーションで問題が発生します。攻撃者が特定のリクエストで一貫して発生するエラー500を見つけた場合、それはアプリケーションがエラーを処理できず、エラー条件も処理しなかったことを示しています。たぶん、わずかな変化が悪いことを起こすかもしれません...
ただし、500コードを単に400に置き換えるだけでは、真の解決策ではありません。実際の問題を隠すだけです。 ブラックボックス侵入テスト（コードへのアクセスなし）を行っていた場合、エラーコードの値に依存せず、既知のすべての弱点を試していないため、内部500を400で非表示にします。アプリケーションを保護しません。そして、私は本当に深刻なハッカーが同じように考えると信じています...
専門家の世界では、500個のエラーを分析し、処理されない例外的な状態が原因である場合は、開発者チームにチケットを入力する必要があります。内部アプリケーションの場合、エラー500は（明示的または暗黙的に）意味しますこれは予期しないエラーです。サポートにお問い合わせください
サーバーエラーは通常、サーバーでの攻撃がどれだけ成功したかを全体的に示します。その403のように、特定の認証がサーバーによって正常にブロックされたことを示します（サーバーが特定の不正なアクティビティを非常にうまく処理したことを意味します）が、サーバーが500をスローすると、特定のエラーを処理できなかったため、として混乱しましたその結果、ハッカーは500の関連エラーを利用するためにより多くの努力をする機会が与えられ、サーバーをより深く掘り下げることができます。
つまり、500のエラーは、未処理の何かが発生した場合にのみスローされ、ユーザーがその結果や生成した出力を見ることができないため、危険な場合があります（そのステータスまたは結果は、サーバーに深く侵入するのに効果的です）。