TL;DR Is it a "best practice" to return an HTTP 400 Bad Request response if extra parameters are sent with a request?

I'm putting together a web app and doings some testing with OWASP ZAP. I'm pretty happy with the results - the errors I get seem to be all low confidence and when I inspect the errors in detail, I'm finding that the ZAP tool really didn't change anything with the request. But that leads me to a "higher level" question, which is best explained with an example:

OWASP ZAP allegedly found an SQL injection with the following URL:


in "human-readable" form, that is:

http://example.com/api/client/1?query=query' AND '1'='1' --

Looks like a pretty standard SQL injection attack. Now, this endpoint is intended to return a client object in JSON form, and that's what this request does through OWASP ZAP. The server returned exactly what was expected, the client with ID=1. I'm doing everything that the OWASP ZAP docs recommend with respect to SQL injections, so what more should I do?

It occurs to me that I just don't know what OWASP ZAP expects to receive in response to this kind of attack - an error reponse, perhaps? The docs are helpful, in a "this is how to interface with the database" kind of way, but it's not clear to me if I need to respond with an error.

Should I return a 400 Bad Request error if inappropriate query parameters are provided?

  • Is ?query= a valid parameter? Does the code after the AND actually execute? If not, it's a false positive.
    – HackSlash
    Apr 25, 2019 at 16:39
  • Sorry, maybe my question wasn't clear: this is a false positive (and I recognize that); query is not a parameter I'm using (it's just being ignored by my app).
    – Kryten
    Apr 25, 2019 at 17:59

2 Answers 2


No, you should not be returning a 400 if there are extra query parameters you do not expect.

Reasoning: You are actually making it easier to attack the application. By notifying the attacker that a particular parameter is invalid, they can easily start guessing parameters, and when they receive a 200 instead of a 400, they know they've found a valid parameter which they can try attacking by other means. Additionally, your application is no less secure when the false positive is reported. Adding logic to return a 400 is more work without an additional pay-off

  • Thank you. This clears it up for me. I kind of thought this was the way to look at it.
    – Kryten
    Apr 25, 2019 at 18:01

Should I return a 400 Bad Request error if inappropriate query parameters are provided?

That is not a bad idea and along with a whitelist approach this can be used for a variety of scenarios.

Is it a "best practice" to return an HTTP 400 Bad Request

Well that is tricky question and to answer that you will have to look at variety of web application attack's and none of them will tell you that is the solution. While a whitelist can be a good approach but "best practice" is different for many a attacks.You specifically ask about SQL injection.SQL injection best practice is to use Prepared Statements (with Parameterized Queries).Try solving sql injection using a whitelist,you simply cant.

so what more should I do?

That takes us to "how to approach web application security?"

You need to understand that any automated attacks will most likely yield easy bugs.They also wont cover any logic attacks that your application might have.Apart from that in order to write secure web application code i would suggest OWASP CHEATSHEET SERIES (https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets). I have yet to find anything better. Happy coding!.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.