When invalid querystring paramater detected in a web page url: throw an error or ignore?

Question

What is a better practice to deal with users modifying the query parameters of a website: to throw an error or to ignore?

For example, someone tries to assign "abc" string instead of number to a page parameter:

http://example.com/list/?page=abc

Should the website show the list items anyway with the default first page, or should it give 404 error?

Answer 1

You will get different answers in different Stack Exchange sites.

UX POV

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
 Site homepage:http://www.example.com

Do you need to contact our [technical](mailto:[email protected]] support or our webmaster?

Technical details:
 Request: GET www.example.com/products?page=w HTTP/1.1
 Response: HTTP 400 (bad request)
 Error: argument "page" must be numeric
 Referrer: www.brokenlinks.com

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.

Security POV

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

Answer 2

Changing the URL in the browser is absolutely not "hacking" *. That's just a basic feature of the web: you can modify the URL as you see fit. What you are essentially asking here is "what if the URL does not return a valid resource?" You show a 404.

* at least in the context of the vernacular definition of hacking that is used these days that refers to attempting something malicious

Answer 3

Scenario:

I am a blogger, and I want to link to content on your website. In creating my link, I make a typo, and my link reads:.http://example.com/list/?page=q23

Now, a different user, a reader of the blog, clicks that link. It would be less than desirable if the first thing they see is "stop hacking", or even the generic error screen your programming language of choice provides. Instead, ask yourself:

• How might my user have ended up here?
• What were they trying to accomplish when they ended up here?
• How can I best help them accomplish what they set out to do?

Depending on what you've received in your query string, you can show them pages with similar terms, or direct them to the correct page for viewing a list of results. It's also common to throw a friendly 404 with a search bar for your websites content as the main CTA on the page.

Technical:

• Log the "referrer" and attempted URL for bad requests (see if you can identify trends)
• You're taking in a query string. Program accordingly to protect yourself from vulnerabilities (there are plenty of resources on this)