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
    Commented 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
    Commented Apr 25, 2019 at 17:59
  • When making a decision regarding this topic, maybe there are (besides security) other relevant things to consider. For example when building a REST API used by other parties it would be useful for the consumers of the API to be notified about invalid request parameters from a developer point of view.
    – Wilt
    Commented Jan 17 at 8:28

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
    Commented Apr 25, 2019 at 18:01
  • 1
    How does this approach increase security? Under this approach someone could post numerous possible id parameter names with an id on a GET request, and if any one is correct, they get a successful response with your data. Typically the response will make the correct parameter obvious as well. So now instead of attempting one request at a time (which allows for rules to prevent programmatic attacks) an attacker can attempt as many parameters as fits into the query string (probably 1024 or 2048 characters). What am I missing?
    – TCooper
    Commented Jun 23, 2022 at 15:49

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!.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .