Prior to making the parameter validators, an object is created where the object property keys are built from the parameters in and name properties. However, these properties are not existent on $ref parameters and, since $ref parameters are resolved after making this object, all of the $ref parameters get conflicting keys.
Also, the keys of this object are not even used, so there doesn't seem to be any point to it all. Maybe the point of it is so that def.parameters get overridden by operation.parameters. However, this is coming at the expense of $ref parameters not being validated.
Wow, what a horrific bug to exist for so long... Maybe it's a stretch to call it a security hole, but close. No validation occurs on these endpoints as a result.
Prior to making the parameter validators, an object is created where the object property keys are built from the parameters
in
andname
properties. However, these properties are not existent on $ref parameters and, since $ref parameters are resolved after making this object, all of the $ref parameters get conflicting keys.Also, the keys of this object are not even used, so there doesn't seem to be any point to it all. Maybe the point of it is so that
def.parameters
get overridden byoperation.parameters
. However, this is coming at the expense of $ref parameters not being validated.