note sundialsvc4 It also occurs to me to wonder, and with considerable alarm, “exactly what is it about your present algorithm which makes you care that an ‘extra’ parameter value is appearing in the data?”   Of particular concern to me is that perhaps the software is iterating through the parameters given and attempting to do something with them “no matter what they are,” on the very naïve and very dangerous assumption that only the “expected” parameter-names could actually be there.   (PHP was most-notorious for this in its earliest days, when it would “helpfully” introduce every POST/GET variable that it saw, right into the variable pool.   “Helpful” indeed it was, if one is not thinking of malice, and of course it didn’t last long.   But there are still probably some vulnerable web-sites out there that are still being hacked because of it.)   Your application should know exactly what variable-names it might consider.   It should look only for submitted variables under those names, at the exclusion of any and all others.   It should, furthermore, validate each of these, using a regular-expression (say), before accepting any of them.   Never allow the user (which could well actually be a malicious “bot!”) to “stuff” anything into your application’s brain. (Edit:   Parameter validation should always occur in two places.   First, the user interface should filter out typographic errors before attempting to submit anything to the host.   But second, the host should validate everything it receives, both syntactically then semantically.   I am of the opinion that, if anything is found to be wrong in second-stage verification, the host perhaps should throw-out all of it, and perhaps using <tt>400 Bad Request</tt>.   Ditto the presence of “unexpected” parameters in the input, on the rationale that it is “a bug, at best” for them to be present.   The client-side validation is for user convenience (and to reduce network bandwidth); the second is for the server’s own protection and to facilitate the detection of legitimate errors “somewhere” in the software.   (Even in 100%-innocuous scenarios, the hardest thing about troubleshooting any problem is knowing that a problem exists.) 1011634 1011634