Skip to content

UseForwardedHeaders should raise more prominent errors for unknown proxies #58461

Open
@halter73

Description

We have a general rule that errors that can be caused by a misbehaving client connected to a well-configured and functioning web app should not raise log messages higher than the debug level because it could allow attackers to effectively spam the logs. This is a principle we follow in the ForwardedHeadersMiddleware. However, this makes it much harder to figure out what's going on when the middleware ignores X-Forwarded-... headers because the request comes from an "unknown" proxy in development. See #58455 and #57650 for some recent examples of this.

The only indication that things are going wrong (other than HttpRequest.Host and some other properties not getting set to the expected forwarded values) is the following log:

dbug: Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersMiddleware[1]
     Unknown proxy: [::ffff:10.0.0.100]:54321

Raising the severity of the log only in development seems like one of the easiest possible fixes, but most of the time this issue only occurs after deploying to a production environment. Another option would be to reject requests containing X-Forwarded- headers from an unknown source with a 400 status and a description of the issue in the response body even in production, but that seems like a very risky breaking change.

I'm not sure what the best solution is, but the current behavior has wasted a lot of people's time debugging.

Metadata

Assignees

No one assigned

    Labels

    area-middlewareIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlesware

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions