17

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?

  • 28
    It's worth noting that if your site is poorly designed (for example full of ads) it might be easier to try and change the URL to visit page two (or whatever) than find and click the link to page 2. I've used way too many websites where it's easier to manipulate the URL manually than navigate with the websites offered tools. – aslum Oct 6 '15 at 14:45
  • 7
    Better yet, imagine this situation. Your site is www.daycarereviews.com and it has a pagination system, now someone maliciously hosts links to your website as www.daycarereviews.com?page=weird_pron_stuff So now Google crawls their site and sees a link to your site which produces error free results so your site could potentially be known for weird_pron_stuff now – MonkeyZeus Oct 6 '15 at 16:31
  • 3
    @Majo0od "pron" or even "pr0n" are slang for "porn". – xehpuk Oct 7 '15 at 12:49
  • 4
    weird pron stuff unite! Check the URL ( ͡° ͜ʖ ͡°) – MonkeyZeus Oct 7 '15 at 12:50
  • 6
    @xehpuk It has begun. Please don't ban me Lords of StackExchange :( – MonkeyZeus Oct 7 '15 at 12:59
20

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:support@example.com] 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).

  • For a syntactically well-formed HTTP request (i.e. one that Apache/Nginx/whatever doesn't immediately error on before even hitting your code), HTTP 400 is arguably incorrect. I would suggest borrowing 404 for this purpose instead, since just about everyone who sees a 404 immediately knows it means "that's a bad URL." – Kevin Oct 6 '15 at 15:26
  • 2
    @Kevin I'd use 404 only when a resource doesn't exist. For example in www.example.com?page=1&pageSize=A is not a 404 because resource exists but request (in a broader sense) is malformed (there is a letter where we expect a number). Note that www.example.com?page=1000&pageSize=20 may return 404 (if page number 1000 is out of range). Unfortunately there isn't a specific error code to use but it's not a 404 error (IMO). – Adriano Repetti Oct 6 '15 at 15:34
  • As @njzk2 said in the comments I think it may just be a 400 error – DasBeasto Oct 6 '15 at 15:57
  • 2
    @Kevin User-friendliness has to do with the response body, not the choice of error code. You can have a friendly 400 or an unfriendly 404. – Random832 Oct 6 '15 at 17:41
  • 1
    @DanHenderson it depends how you define better experience. Usually if I write something wrong then I want to be notified, I don't need/want an application automatically show me wrong results (wrong because it's not what I asked for). Imagine: www.example.com/healthcare/patients?RiskFactor=smoke. It looks right however right word may be smoker. System should not silently give complete patient list. What it should do is to tell me I was wrong (but also suggesting me the right URL if it can be inferred). – Adriano Repetti Oct 7 '15 at 13:12
22

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

  • 4
    It's a basic feature of the web, yes, but I'd also say it is hacking, because hacking is really just playing around with things (in this case URLs) in ways that were not necessarily intended to see how they react. It's not necessarily malicious hacking, though. – David Z Oct 6 '15 at 16:53
  • 1
    As far as I know "url hacking" is an established term for playing around with urls (either to explore a site or to speed up navigation) – kapex Oct 6 '15 at 17:56
  • 1
    @kapep ah so it is, never knew, this site (I advise having adblock for it) talks a bit about it. – DasBeasto Oct 6 '15 at 18:13
  • Technically, for poorly secured websites by changing URL query parameters you can perform SQL injection hack or something similar. – Aidas Bendoraitis Oct 6 '15 at 18:21
  • Actually it is hacking - someone has been convicted of it before. arstechnica.com/tech-policy/2012/11/… – Dar Brett Oct 7 '15 at 7:30
9

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)

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.