You will get different answers in different Stack Exchange sites.
It may be a copy & paste error or a (power-) user typo, not necessarily a malicious attack to site security.
I'm (generally) against silently ignored errors because error may go unnoticed and what user get won't be what he expects.
I'd always throw the appropriate error. For a web site a malformed query string may return HTTP 400 status code (Bad Request, read further for short discussion about this) with an appropriate error page.
Custom error page (any decent site should have custom error pages for common errors) is the place where users will understand what's wrong (status code, it doesn't matter which one, is almost never explicative for non-technical users). In such page you will put:
- An user-friendly error description that even non-technical users will understand.
- A possible solution.
- If you detected an error you can correct (for example a string instead of a number in the URL which can be defaulted to a reasonable value) also put a link to adjusted URL.
- Optionally provide spell check functionality for the failed address.
- Provide a link to webmaster/technical support to submit support requests.
- Always log failed requests (and notify webmaster when referrer is your own site), most users won't submit any notification and broken link may be inside your own site, that's a terrible User Experience.
Address you entered is not valid.
Possible causes and solutions:
• If you directly typed this address please check for typos.
• If you copied & pasted this address please check you included entire address (for example e-mail programs may split addresses over multiple lines and you need to recompose them manually).
• If you arrived to this page following a link please notify source site owner that link is broken.
These are possible pages you may want to view instead:
Similar page: http://www.example.com/products?page=2
Products catalog: http://www.example.com/products/index
Do you need to contact our [technical](mailto:firstname.lastname@example.org] support or our webmaster?
Request: GET www.example.com/products?page=w HTTP/1.1
Response: HTTP 400 (bad request)
Error: argument "page" must be numeric
Note that this schema is not limited to this specific case (or to 400/404 status codes). You error messages/pages must always be useful and user friendly, see also “No video device” feedback examples.
From a security POV a bad request may be an attempt to break your security.
You have different options and actions. This section is far to be accurate and exhaustive then asks security experts (in your team or, at least, at security.stackexchange.com) for better approaches.
Assuming (see above) user may type a wrong URL you can't consider them a malicious attack however not all URLs are born equal. You may have, for example, a visible URL
/Home and a GET request to fetch items in a list with
/Home/News?page=1&itemsPerPage=5&mode=overview; user won't ever see 2nd URL because it's an AJAX requested by main page to fetch content for a page element.
In general invalid parameters for URLs accessed only through AJAX requests should be handled as potentially attacks. You may:
- Simply return an error page (with or without 40x HTTP status code). User won't see this unless he inspects Browser developers tools.
- Optionally add a delay (to slow them down if they're trying a brute force attack (!) using random query strings). Be careful it may be counterproductive if they can generate a huge number of parallel requests because it may cause a DoS in your server.
- If multiple bad requests happen in sequence from same source you may apply a temporary blacklist.
- If multiple bad requests happen in sequence to same target resource then you may slow them down (same reason of point 2) and eventually redirecting them to a fictional web-site (example.com) with HTTP 301 or 307.
Which Error Code?
I do not think it's an important point (especially if users are human beings) but...which HTTP error code we should use? Someone suggests 404 however:
The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.
Obviously it's not the case for a malformed URL (for example
www.example.com?page=1&pageSize=A). 404 may be an acceptable status code if URL was
www.example.com?page=1000&pageSize=20. For 400 status code we know (as better described by HTTPbis):
The 400 (Bad Request) status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical, or exceeds some limitation on what the server is willing to process.
It obsoletes RFC 2616 where appropriate error code for logical errors were unclear. Note that (for what it matters) you may adhere to RFC 4918 (updated by RFC 5689) and use status code 422:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
But all these said...this is an almost useless detail (in this case), for example Stack Overflow sometimes returns 200 in both cases (...and silently ignore malformed URLs using defaults) and sometimes it returns 404 (page not found) depending on which URL parameter you're writing wrong. Pick an error code and return proper page (this is the important part, see also MonkeyZeus comment).