this change will allow disabling use of the "referer" header when generating a "previous" URL. to maintain backwards compatibility it is by default enabled.

while the risk is small, headers can be manipulated by things like MITM attacks, so we shouldn't rely on unvalidated user input to control our redirect.

I previously submitted PR#57533 which allows us to enforce the same origin on a redirect. while this is a good addition, as I was writing some documentation for it, I realized it didn't actually go far enough. this only handledexplicit calls of building aRedirectResponse, such as with theback() method. However, it failed to address the implicit calls the framework itself makes to the underlyingUrlGenerator::previous(), such as the automatic redirection that occurs whenValidationExceptions are thrown. this PR gets to the root of the problem, and provides a way to disable the header use globally.

I'm sure some people reading this will be saying I'm making a mountain out of a molehill, and while I tend to agree the risk is small, I still think it's important to allow the developer to choose here. As I and others have mentioned, this "vulnerability" does often show up in audits. Even though the threat vector is small, and there are possibly a handful of other security best practices that must also be missed/ignored for this to be viable, internal and/or external stakeholders still may want to see this fixed. As a personal anecdote, this "vulnerability" is currently holding up my company from closing a deal with a new customer.

Given the fact that we can also pull a previous URL from the session (something we have more strict control over), I've been racking my brain over the last week of an actual use case of wanting to allow an external URL to hit our application, and then sending the user back to that external URL. I could not come up with any, but maybe they do exist, and would love to hear if anyone has one. This goes more to the question of if we would make any adjustments in v13, but that can be a separate discussion.

I'm not 100% sure how we are handling config values now, so let me know if this change was incorrect.