fix(security): request object leakage

[prgTW]

Q	A
Branch?	patch versions for both 2.x and 3.x branches
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Fixed tickets	#280
License	MIT
Doc PR

matching can happen on other things than the path and method. i think we should adjust the message a bit to not lead people to only look at the path and be confused.

@dbu Hey 👋. I've read the above message from #280, but just wanted to fix a security issue at hand instead of thinking what should be the proper exception message.

[dbu]

thanks for looking into this - the original issue went under, it seems.

i fear we need to do this. its annoying for debugging, but security is more important.
i asked in symfony slack if there is a default way of symfony to securely log the request without confidential fields, but if nothing great comes up, lets just reduce to the path.

you say you want to fix this for 2.x as well - can you please make the pull request against the 2.x branch? i would want it there first, and then update the 3.x branch from 2.x to keep things in sync without conflicts.

and can you please add a changelog entry in the pull request to 2.x that explains what changes and why it is done?

[prgTW]

In order to fix this in 2.x (2.3.5 preferably) there would need to be a branch made from bbcdf2f (which is 2.3.4) to which I could make a PR to. Can You provide such a branch, named 2.3?

[dbu]

Can You provide such a branch

i created the 2.x branch from 2.3.4

but then noticed that that branch is restricted to symfony 4 and 5. and code rot of course has taken its toll, most builds fail for the 2.x branch. given how old version 2 is, i feel its enough if we fix the issue in 3.x. but if you really want to do it for 2.x, the branch now exists. given the situation i would merge it with failing ci (just make sure the formatting of the exception stays the same for the non framework use case so that our own test does not fail).