Best practice for URL parameters [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

How much important is it to secure the URL parameters naming? Is ?user_id=3 less secure then ?uid=3 or ?u=3 or just /user/3? Should I really consider making parameters hard to guess?

Answer 1

Obscurity is no security at all. The only reasonable factors to consider are readability/prettiness of links. If you have 200-character links, they are not memorable, and are kind of hard to paste, and consume a lot of space (e.g. can't send through SMS, and they're hard to type on a mobile); on the other hand, it's easier to have confidence in a link if you can understand its semantics.

Answer 2

The userid should be a session variable, and the session id should be in a cookie.

Some security information says to avoid all URL variables, but that is just security through obscurity. The point is, if it comes through to the user from any source $_GET, $_POST, $_COOKIE, $_SERVER, $_REQUEST, $_FILE... You need to sanitize it. By:

• Using a white list wherever possible
• Using RegEx and type checking all input before used
• If it will be displayed, remove HTML
  • using strip_tags() [if there are some allowed tags]
  • or htmlentities() [prefered]
• Use prepared statements (mysqli or PDO are common libraries that can do prepared statements for MySQL databases) for all database queries to prevent SQL injection
• Use nounce to prevent XSFR attack and accident form resubmission
• If its a file check mime type (not just the mime type in the $FILE array) before moving it

TL;DR: Using mod_rewrite is hide variable's real names might not be a terrible idea, and may make your urls "prettier" to the user -- but it is not a huge security gain.

Answer 3

In general, I have found that consideration of implementation is critical. Is this going to be used by you and a couple friends? It's probably less important, in that case, to worry about what you're naming URL variables.

If the data is sensitive, don't put it in the URL at all - this includes information specific to users, like passwords (which you shouldn't have in plain text anyway), password hashes, email addresses, private information, etc. I don't worry too much about usernames. If the info is important/sensitive, POST it rather than GET.

Using the .htaccess with some rewriteRules can make URLs much easier to remember - for example, website.com/page/1 is considerably more user-friendly than website.com?page=1, particularly when you get more than 1 variable in there. .htaccess rewriterules are not difficult to make, and can help your website look considerably more professional.

In terms of variable NAMES in the url, it again depends on usage. For example, "user=username" would be fine, or even "u=uname" or "uid=username" are acceptable, but if you're worried the user might easily find and change something, that's a big indicator that there's a problem: Not because the user could change something there, (even POST isn't secure, users can POST anything they want) but because your backend should be built to handle it, even IF your users change things in the POST/GET.

TL;DR: Putting GET variables in the URL bar is a courtesy to users. If they will appreciate or make use of it, do it - it's a nice touch. Users don't want you to put sensitive information there, and users don't want it to be too long. Any and all security should be done in the backend, where the user can't tamper with it.

Answer 4

It's a very good question. I do not think it needs to be - or can be - really secure to be honest. And both have advantages. eg

• Make it short and the url will be short. (too long urls can be a problem if you put urls together dynamically)

• Make it long and its easier to debug things later. :)