At the moment non/semi sensitive information is sent from one page to another via GET on our web application. Such as user ID or page number requested etc. Sometimes slightly more sensitive information is passed such as account type, user privileges etc.

[EDIT: I may have worded this wrong, I'm not passing sessionID or actual user privileges, just simple NON-sensitive data - I just don't want the user to see the words easily, does not matter if a more technical user can read it as they cannot do any damage and cause security concerns. read the chat with @delnan]

We currently use base64_encode() and base64_decode() just to de-humanise the information so the end user is not concerned.

Is it good practice or common place for a URL GET to be encrypted rather than simply PHP base64_encoded?

Perhaps using something like, this:

$encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));

$decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($encrypted), MCRYPT_MODE_CBC, md5(md5($key))), "\0");

Is this too much or too power hungry for something as common as the URL GET.

  • Why would you have to base64-encode user IDs and page numbers?
    – user7043
    Mar 31, 2012 at 12:44
  • just to make them non-readable to the user
    – hozza
    Mar 31, 2012 at 12:45
  • And why would you want that?
    – user7043
    Mar 31, 2012 at 12:45
  • 2
    Good for you. I still don't see why you'd have to encode anything. If you don't want the user to see it, pass it as POST or put it in a session. If you want to put it in GET and it's not sensitive, don't encode it pointlessly.
    – user7043
    Mar 31, 2012 at 13:22
  • 1
    @delnan: Passing as POST will hide it from the average user, but that's about it. If it's sensitive, don't pass it to the client, period. :)
    – netcoder
    Mar 31, 2012 at 15:39

3 Answers 3


Why are you using GET in the first place? Just POST the sensitive data over HTTPS, and add suitable CSRF protection.

This is assuming that the information is sensitive in the sense that the authorized user and the server may see it, but others (other users and attackers) must not.

If the user isn't allowed to see the information either, then just don't send it in the first place. Keep it on the server; if you need to link it to the user, pass a session ID back and forth (with the usualy precautions and safeguards in place), and store the sensitive information in the session (that is, server-side).

Sending sensitive information to an unauthorized client is sloppy, because it gives the attacker an opportunity for off-line cracking methods.

  • 1
    The user is allowed to see the information, read the comments/chat on the question and perhaps this will better explain my situation. I however do value parts of your answer.
    – hozza
    Mar 31, 2012 at 22:11
  • 1
    @hozza: in that case, the first paragraph is pretty much your answer. Just POST over HTTPS, and the data will be encrypted at the transport layer (GET over HTTPS will do the same, but the unencrypted data shows up in the browser history and such).
    – tdammers
    Apr 1, 2012 at 12:26
  • To my knowledge, I can't use POST with a '<a href="">' and I cannot use HTTPS at the moment.
    – hozza
    Apr 2, 2012 at 18:55
  • @hozza then don't use an anchor, use a form. Apr 20, 2012 at 6:01

If you pass just UserID something like Page Number then just URL GET is fine. If you do not need any explicit security on them, it would be a overhead for you.


Passing information this way is a hazard waiting to be exploited. You need to think about what someone who understood the traffic could do to the site that is accepting the GET.

  • You should use POST
  • If any sensitive data is being passed, it should be encrypted.
  • You should checksum and sign the package of data so it can't be altered and similar packages can't be constructed.
  • Thank you, but how can I use POST with standard HTML '<a href="">'?
    – hozza
    Apr 2, 2012 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.