I have come across a website, freshbooks.com, which uses base64 encoded urls for all purposes, ranging from POSTing sensitive data to a URI or just viewing some resource.

For instance, a url to view an invoice on the website is (some part of url omitted for clarity):


When the string dmlld0ludm9pY2VGQjU1Mzc2 is decoded it gives viewInvoiceFB55376

Are there any reasons from security point of view to use URL in such format or just for some programming convenience. The only reason I can think is to prevent some automated tools to extract information about website design. If so, isn't this approach be characterized as security by obscurity?

3 Answers 3


There's absolutely no security gain from using this method of presenting the URLs. This is just a silly way of making the website "production-ready" (whatever that means). In fact, it's not even a programming convenience; it's the exact opposite. It makes debugging much more difficult especially when you have to find a specific string in a URL in the log files.

The developers of that site might have opted to make the website appear more secure by having cryptic URLs and whatnot. However, that doesn't mean this is security by obscurity.

If their website is vulnerable to SQL injection and they try to hide that by encoding the URLs, then it's security by obscurity. If their website is well secured against SQL injection; XSS; CSRF; etc., and they deiced to encode the URLs like that, then it's just plain stupidity.

Note: I've heard people argue that encoding the URLs might hide certain information from shoulder-surfers, or that it can help reduce crawling, or any number of arguments of that sort. I still find this technique silly for the reasons I mentioned above.

  • 1
    -1 because this answer is full of assumptions and they're all entirely wrong. One very valid reason for encoding the URL in this way is to simply avoid having .FILE_EXTENSION in a path, to avoid having the web server default handlers kick in and "steal" your route. You tear this concept apart as being a pathetic attempt at bad security design, while in fact perhaps the route handler for that type of URL is employing all kinds of fantastic security, performing authentication on the request then serving up secured files beyond the web root.
    – user7933
    Commented Feb 12, 2016 at 13:30
  • @TechnikEmpire Thanks for your input. Here's why I disagree with it: Route handling in web applications and web services is done at the web server level using rewrite rules that "redirects" request to a central entry point that handles the routing. That's the proper way to do it. That's how every single decent framework does it. Two and a half years later, I still think that there's absolutely no legitimate reason to base64-encode URLs. Of course, if you're a bad coder or a sysadmin who doesn't know how to configure a web server, then by all means encode as much as you like to cover for it.
    – Adi
    Commented Feb 12, 2016 at 14:17
  • Additionally, the question is specifically asking for the reason from a security point of view.
    – Adi
    Commented Feb 12, 2016 at 14:19
  • 1
    Actually he's asking if it makes it more secure, but you're taking it and answering it as if he's asking "They did this for security, is this secure". This whole answer is based on a straw man really. That's my main problem with it. My second problem with it is how you inject these sweeping allegations, like your line about how you're a bad programmer if you do this etc, yet none of those assertions can be backed up they're just wild speculation based on personal preference. This answer offers nothing but that.
    – user7933
    Commented Feb 12, 2016 at 15:48
  • @TechnikEmpire Cool, mate.
    – Adi
    Commented Feb 12, 2016 at 16:11

Base64 can be useful for passing data in URLs when that data includes non-url friendly characters, although even then, there are options.

The structure of what you have decoded actually seems to suggest that the encoded string is a command with parameters, which could suggest an reliance of Base64 for Injection attacks, like @Adnan said.

My best guess is that it's a misguided attempt at strengthening security.


HTTP URLs may be Base64 encoded not for security reasons, but for application reasons, specific to that web server.

I'll draw upon my experience with ASP.NET MVC which may or may not apply to your situation.

It is perfectly reasonable, although not user friendly, to encode data that may be mis-interpreted by the browser, or an MVC framework. Base64 works when UrlEncoding doesn't. For example, I have a / character I want to send to another server as a payload www.server.com/invoice.aspx?filehash=somedata1293/323222, Base64 encoding, or HTTP POST, is the only way to send the value of filehash in ASP.NET MVC without custom routes.

If I want to GET that data, then I would have to Base64 encode it.

Even though there are better solutions, I've seen this approach taken in internationalized applications supporting different character sets.

It is a bad idea, however, to consider Base64 encoding as a security measure since at most it will make casual URL "hacking" slightly more challenging for the novice. And yes, in this case it would be security by obscurity.

  • Or, maybe, filehash=somedata1293%2F323222. Just like URL encoding was meant to be used. Alternative, UTF-8 can be used to comply with the newer RFC 3986. I've seen Base64 used so many times and not one time there was one logical reason for the usage. Your answer is not different.
    – Adi
    Commented Dec 3, 2013 at 16:00
  • @Adnan Perhaps this is a platform issue, specific to ASP.NET MVC? My test website seems to interpret encoded urls as the incorrect route. e.g. append the encoded version of ?callback=http://host.com/test Commented Dec 3, 2013 at 16:03
  • Thanks for your suggestion. Still, the main point of the question is the security aspect.
    – Adi
    Commented Dec 3, 2013 at 16:18
  • Exactly... my point is that it may not be a security issue at all, though it's easy to assume that all reasons things are done are security related when viewed in the context of this site. Commented Dec 3, 2013 at 16:25
  • 1
    +1 this is the right answer. There's nothing bad about this mechanism, it is not some terrible attempt at security through obscurity, and its most likely actually very secure and serving up files post-authentication through a custom route that serves protected files kept beyond the reach of the web root.
    – user7933
    Commented Feb 12, 2016 at 13:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .