application_security/error_handling

9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Use flat Promise chains instead of callback nesting

Avoid deeply nested callback functions ("Callback Hell" or "Pyramid of Doom") which make error handling difficult. Use flat Promise chains with `.then()` and `.catch()` to ensure errors skip over `.then` functions and invoke the first `.catch()`. Alternatively, use async/await with try/catch blocks. If a module does not support Promises, convert it using `Promise.promisifyAll()`.

Handle uncaughtException to prevent undefined state

Bind to the process `uncaughtException` event to handle uncaught exceptions. Clean up allocated resources (file descriptors, handles) before shutting down. Call `process.exit()` to terminate the process, as resuming is strongly discouraged due to unknown application state. Do not reveal detailed error information like stack traces to users; show custom error messages instead to avoid information leakage.

Listen to error events from EventEmitter objects

Always bind to the `error` event when using EventEmitter objects. If an error occurs in an EventEmitter and no listener is attached to the error event, the Error is thrown as an uncaught exception, crashing the application. Proper error event handling prevents unhandled exceptions.

Handle errors in asynchronous callbacks with Error as first argument

Errors in asynchronous callbacks are easy to miss. By convention, the first argument to asynchronous functions should be an Error object. In Express routes, errors in async callbacks within the route are not automatically handled unless an Error is passed as the first argument. Each callback that receives a propagated error can ignore, handle, or propagate it further.

Error handling prevents information disclosure

Respond with generic error messages and avoid revealing details of the failure unnecessarily. Do not pass technical details such as call stacks or other internal hints to the client.

HTTP status codes for REST API security

Use semantically appropriate HTTP status codes for REST API responses. Key security-related status codes: `200 OK` (successful action), `201 Created` (resource created, URI in Location header), `400 Bad Request` (malformed request), `401 Unauthorized` (wrong/no authentication), `403 Forbidden` (authenticated but no permission), `404 Not Found` (non-existent resource), `405 Method Not Allowed` (unexpected HTTP method), `406 Unacceptable` (unsupported Accept header content type), `413 Payload Too Large` (request size exceeded limit), `415 Unsupported Media Type` (unsupported content type), `429 Too Many Requests` (DOS/rate limiting), `500 Internal Server Error` (do not reveal internal details), `503 Service Unavailable` (temporarily unable to process).

Symfony error handling in production vs development

By default, Symfony displays detailed error messages only in the development environment. In production, a generic error page is shown for security reasons. Symfony logs detailed error information, which aids developers in identifying and resolving issues efficiently.

gRPC secure error handling in Go

Log detailed error information server-side with log.Printf() while returning generic error messages to clients. For example: log server-side error with log.Printf("Payment validation failed for user %s: %v", getUserID(ctx), err) but return to client with status.Error(codes.InvalidArgument, "invalid payment request").

gRPC status codes for error responses

Use appropriate gRPC status codes: codes.Unauthenticated for authentication failures, codes.PermissionDenied for authorization failures, codes.InvalidArgument for validation errors.

Give your agent this brain