Currently we have the excluded_http_codes setting, which defaults per recipe to [404, 405] (https://github.com/symfony/recipes/blob/main/symfony/monolog-bundle/3.7/config/packages/monolog.yaml#L39) for regular logging.
This is weird behavior when considering the HTTP spec, and by proxy therefore even a Denial of Service loophole, as the entire 4xx class of errors can by definition be caused at will by external parties. Malformed requests give 400 Bad Request, but when building APIs also 416 Range not Satisfiable and 422 Unprocessable content. This allows attackers to flood a server's disk with logs, causing downtime. Most HTTP 4xx errors can be trivially triggered externally on API servers.
Similarly bad, when using Monolog to escalate to targets like email, Slack etc. you definitely want to exclude the entire 4xx range of errors, as the HTTP specs explicitly state that those errors are expected and repeatable: if a client does not modify its request after a 4xx response it is nearly always expected to get the same result (excluding 429 Too Many Requests, and code changes in the meantime).
Current default behavior allows malicious external parties to flood server storage, mailboxes, Slack channels, logging tools remotely at will. That's bad.
For such handlers we definitely need to implement an exclude_http_client_errors setting, which drops all error codes between 400 and 500.
(yes I am aware that this would need to be implemented in the monolog bridge first but it's optically a feature of the bundle, so discussing here)
Currently we have the
excluded_http_codessetting, which defaults per recipe to[404, 405](https://github.com/symfony/recipes/blob/main/symfony/monolog-bundle/3.7/config/packages/monolog.yaml#L39) for regular logging.This is weird behavior when considering the HTTP spec, and by proxy therefore even a Denial of Service loophole, as the entire 4xx class of errors can by definition be caused at will by external parties. Malformed requests give
400 Bad Request, but when building APIs also416 Range not Satisfiableand422 Unprocessablecontent. This allows attackers to flood a server's disk with logs, causing downtime. Most HTTP 4xx errors can be trivially triggered externally on API servers.Similarly bad, when using Monolog to escalate to targets like email, Slack etc. you definitely want to exclude the entire 4xx range of errors, as the HTTP specs explicitly state that those errors are expected and repeatable: if a client does not modify its request after a 4xx response it is nearly always expected to get the same result (excluding 429 Too Many Requests, and code changes in the meantime).
Current default behavior allows malicious external parties to flood server storage, mailboxes, Slack channels, logging tools remotely at will. That's bad.
For such handlers we definitely need to implement an
exclude_http_client_errorssetting, which drops all error codes between 400 and 500.(yes I am aware that this would need to be implemented in the monolog bridge first but it's optically a feature of the bundle, so discussing here)