mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-27 10:55:55 +08:00
translate 6.20
This commit is contained in:
@ -978,15 +978,15 @@ null == undefined; // true
|
||||
|
||||
<br/><br/>
|
||||
|
||||
## ![✔] 6.20. Hide error details from clients
|
||||
## ![✔] 6.20. エラーの詳細をクライアントから隠す
|
||||
|
||||
<a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration" target="_blank"><img src="https://img.shields.io/badge/%E2%9C%94%20OWASP%20Threats%20-%20A6:Security%20Misconfiguration%20-green.svg" alt=""/></a>
|
||||
|
||||
**TL;DR:** An integrated express error handler hides the error details by default. However, great are the chances that you implement your own error handling logic with custom Error objects (considered by many as a best practice). If you do so, ensure not to return the entire Error object to the client, which might contain some sensitive application details
|
||||
**TL;DR:** 統合されている express のエラーハンドラはデフォルトでエラーの詳細を隠します。しかし、(多くの人がベストプラクティスだと考えている)カスタムエラーオブジェクトを使用して独自のエラー処理ロジックを実装する可能性は大いにあります。その場合、クライアントに、機密なアプリケーション詳細を含む恐れのあるエラーオブジェクト全体を返さないようにしてください。
|
||||
|
||||
**Otherwise:** Sensitive application details such as server file paths, third party modules in use, and other internal workflows of the application which could be exploited by an attacker, could be leaked from information found in a stack trace
|
||||
**さもないと:** 攻撃者によって悪用される可能性のある、サーバファイルのパス、使用中のサードパーティモジュール、アプリケーションのその他内部ワークフローなど、機密性の高いアプリケーションの詳細情報が、スタックトレース内に残された情報から漏洩する可能性があります。
|
||||
|
||||
🔗 [**Read More: Hide error details from client**](/sections/security/hideerrors.md)
|
||||
🔗 [**さらに読む: エラーの詳細をクライアントから隠す**](/sections/security/hideerrors.japanese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# Hide error details from client
|
||||
# エラーの詳細をクライアントから隠す
|
||||
|
||||
### One Paragraph Explainer
|
||||
### 一段落説明
|
||||
|
||||
Exposing application error details to the client in production should be avoided due to the risk of exposing sensitive application details such as server file paths, third-party modules in use, and other internal workflows of the application which could be exploited by an attacker.
|
||||
Express comes with a built-in error handler, which takes care of any errors that might be encountered in the app. This default error-handling middleware function is added at the end of the middleware function stack.
|
||||
If you pass an error to `next()` and you do not handle it in a custom error handler, it will be handled by the built-in Express error handler; the error will be written to the client with the stack trace. This behaviour will be true when `NODE_ENV` is set to `development`, however when `NODE_ENV` is set to `production`, the stack trace is not written, only the HTTP response code.
|
||||
サーバファイルのパス、使用中のサードパーティモジュール、その他攻撃者に悪用される可能性のあるアプリケーションの内部ワークフローなど、機密性の高いアプリケーションの詳細情報が漏洩するリスクがあるため、本番環境においてクライアントにアプリケーションエラーの詳細を晒すべきではありません。
|
||||
Express には、アプリ内で発生する恐れのあるエラーを処理するエラーハンドラが組み込まれています。このデフォルトのエラー処理ミドルウェア関数は、ミドルウェア関数スタックの最後に追加されます。
|
||||
エラーを `next()` に渡し、カスタムエラーハンドラで処理しない場合は、組み込みの Express エラーハンドラで処理されます。エラーはスタックトレースと共にクライアントに書き込まれます。この動作は `NODE_ENV` が `development` に設定されている場合に有効ですが、`NODE_ENV` が `production` に設定されている場合は、スタックトレースは書き込まれず、HTTP レスポンスコードのみが書き込まれます。
|
||||
|
||||
### Code example: Express error handler
|
||||
### コード例: Express エラーハンドラ
|
||||
|
||||
```javascript
|
||||
// production error handler
|
||||
// no stacktraces leaked to user
|
||||
// 本番のエラーハンドラ
|
||||
// スタックトレースがユーザーに漏洩しない
|
||||
app.use((err, req, res, next) => {
|
||||
res.status(err.status || 500);
|
||||
res.render('error', {
|
||||
@ -20,6 +20,6 @@ app.use((err, req, res, next) => {
|
||||
});
|
||||
```
|
||||
|
||||
### Additional resources
|
||||
### その他のリソース
|
||||
|
||||
🔗 [Express.js error handling documentation](https://expressjs.com/en/guide/error-handling.html)
|
||||
🔗 [Express.js エラーハンドリングドキュメント](https://expressjs.com/en/guide/error-handling.html)
|
||||
|
||||
Reference in New Issue
Block a user