EDIT There have been upvotes retracted or downvotes due to, I think, a serious misunderstanding of my question. In the following I'm not concerned about the URL leading to a site containing malware or exploits (not that it's not a concern: it's simply not what this question is about): I'm concerned about injection in the URL string itself. What I don't want is a pirate being able to dodge "whatever framework" security and be able to inject, say, JavaScript code in an URL that I would then display to other users. In other words: I'm looking for an additional measure to lower the risk of rogue JavaScript running as if it was coming from my webapp.

In order to harden a webapp, I'm thinking about never ever displaying URLs input by users and yet allow them to input URLs but always use an URL shortener service. This is not meant to replace other good security practices but to be used in addition to other security practices.

Here's a very simple scenario:

  1. the only thing that one user can input to the website is a single URL
  2. the URL sent by the user is sent to an external URL shortener service
  3. the shortened URL is then served from my website

If during the first step we consider that my parser doesn't have flaws while parsing the POST parameters sent by the user, what can go wrong later on if there's a succesful exploit in the URL that would affect the URL shortener service?

Basically my idea would be to serve, say, an hardcoded:


followed by a very strict rule saying someting like: "insert at most 9 characters and these characters have to be alphanumeric".

I'd do that in order to simplify the rule concerning which characters can and cannot be sent by the user: the output of a bit.ly URL is way simpler than what legit URLs allow (I used bit.ly as an example, any URL shortener service using a very strict subset of characters in the shortened URLs it returns would do).

So what would the worst case scenario be if we consider that the rogue user is unable to exploit my website but still manages to exploit a flaw in the URL shortener service?

What I'd like to better figure out is what it means when it comes to same origin policy / XSS and CSRF and other types of exploits.

And, I guess, my question could be resumed like this: "If security is done correctly on my website, would XSS exploits affecting the URL shortening service still be my concern or not?"

The whole idea would be to add defense-in-depth and to consider that URL shortening service probably know how to defend themselves about URL injections.

  • I'd like to point out that I find it very very sad that most questions here gets answered with, basically: "This is a solved problem, it's very easy to do a, b and c to dodge exploit x, y or z", Yet we're seeing exploits exploiting trivial security holes daily. So it would be nice if the mindset of security-aware people would change from: "It's easy, all you need is to parse/sanitize/etc." to a more open-minded and pro-active way of thinking... Commented Apr 9, 2013 at 16:03
  • I don't think anyone is trivializing your problem or computer security in general. However very few people have a complete mastery of the field. You've made several edits to the question so many responders such as myself probably didn't understand your question.
    – Kyle
    Commented Apr 23, 2013 at 5:37

3 Answers 3


This is an inefficient way of doing things.The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc. However, you are still relying on their security that they will indeed shorten the URL provided by the user, they will be up 100% of the time, and have 0 security vulnerabilities. Why not write your own little parser that verifies URL's. Somethings like this: https://stackoverflow.com/questions/205923/best-way-to-handle-security-and-avoid-xss-with-user-entered-urls

Some things you can look for:

1-The users have indeed entered a url starting with http:// and not some random java script code.

2- you can also use google safe browsing api to check the URL for malware. https://developers.google.com/safe-browsing/, this is very helpful as the google safebrowsing API will return malware for malware and 200 for valid URLS, for anything else such as invalid URL's the google api will return nothing.

  • "This is an inefficient way of doing things."... There are only so much URLs an user can submit and all it takes for me is to call the URL shortening service once and saving that result/mapping in my DB. What's innefficient about this? Commented Apr 9, 2013 at 15:40
  • The call to the shortening service, and the database query to save the mapping, will be slower than simply validating the URL in your app.
    – marcoo
    Commented Apr 9, 2013 at 15:42
  • "The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc." But that's kinda precisely the whole point. That's quite an added security: when the latest URL injection comes out, my site ain't affected and it's the URL shortening service that needs to patch his webapp service, not me. Once again: this is not incompatible with other measure, like calling Google's safe-browsing API (also, if you call calling an URL shortener 'inefficient', I wonder what you call calling Google's verification API ; ) Commented Apr 9, 2013 at 15:43
  • "...and the database query to save the mapping" There has to be a database query anyway to save the URL. Doesn't change anything if I'm saving the bit.ly mapping URL or the direct URL in my DB. : ) I agree that there's a price to pay for the call to the URL shortener: that's the price for added security. Commented Apr 9, 2013 at 15:44
  • regarding the Google safe-browsing, there's a serious misunderstanding here: I'm not very concerned about what the URL contains here (not that it's not a valid concern, but it's something else altogether), I'm concerned about the URL itself doing something nasty to my users when they're visiting my site, not when they're visiting the target URL. Commented Apr 9, 2013 at 15:57

It depends on what the URL shortener service does. Presumably it takes an input (the full URL) and produces an output (the smaller URL), storing the mapping from the smaller URL to the full URL in the database. It may also store a hash of the smaller URL to be more efficient and make lookups faster. I am just speculating because the way it works would really depend on your implementation. However, component wise, the SQL likely going to use a database to store the mappings. Also, the service itself might have access to that database to ensure that duplicate mappings do not occur. It would be possible to produce a SQL injection if the URL service directly uses the database and does so poorly. SQL injection can be prevented by using parameterized queries.

Secondly, your URL shortening service would be vulnerable to DOS attacks where more requests than it can handle are performed. This especially applies if it is written poorly and cannot quickly generate unique URLs. However I would not really worry about that too much, DDoS attacks can be launched against anyone.

I think you edited your post to indicate that it's an external shortener service. This does change things because it means it isn't your database that's vulnerable to SQL injection, but someone else's. Really, there's not too much risk involved with this type of service. If someone can manage to inject the database or otherwise hack it, they can cause users to be redirected to the wrong URL, one that they have set up with malicious code. This external service could also be a danger to you because it can return any old URL it wants to. There's nothing forcing them to implement the mapping in good faith. They can easily send you 99% good URLs and 1% malicious URLs to malicious sites that the author of the shortening service has set up. Or the shortening service itself could be compromised, which will indirectly affect your website. Basically, the URL shortening service being hosted externally saves you a lot of headache because you have fewer attacks to worry about. But the most serious attack if the external service is compromised, is that your users will be fed incorrect or malicious URLs. Depending on how the web service to retrieve these URL mappings from the URL service is authenticated, you have the possibility of a MITM attack being executed in order to serve you fake URLs as well. And your web service could potentially be exploited to hack your server also. Again, all of these things depend on implementation of the url shortener service and of the web services and authentication... a lot of factors you have not given us information about.

  • I could throttle user inputs so that I don't hammer the URL shortening service and I take it that the URL shortening service is acting in good faith. I haven't heard URL shortening services returning bad URLs on purpose :-/ Basically what I'd like to understand are the XSS / CSRF and other security implication should security be correct on my site but an exploit able to bypass the URL shortener's security (I'm not that concerned about the URL shortener being itself a rogue site but even if that service was fully hacked/rooted, what would be the implication for my site?). Commented Apr 9, 2013 at 14:55
  • 1
    I wouldn't bother throttling unless you see problems occurring. I suppose it would be vulnerable to XSS attacks. The URL returned by the shortener service could, in fact, be malicious scripts. So you have to do validation to ensure it's actually a URL that you received and not anything else. This might be helpful owasp.org/index.php/…
    – Kyle
    Commented Apr 9, 2013 at 15:09
  • I know about OWASP, it's precisely why I'm looking for additional measure against, say, XSS. What I'm trying to determine is if in this case XSS would still be my problem or not. :-/ (I'll edit to reflect that) Commented Apr 9, 2013 at 15:16
  • @Cedric Martin Well you're basically adding a String taken from an external service to your web page. So yes input sanitation is necessary as you seem to realize. That link shows how to do the proper input sanitation. Once you do that you're not vulnerable to XSS attacks, at least from that URL service. Defense in depth in this case just means verifying that you're actually receiving a URL, and that the URL shortener service response doesn't contain anything else. That's really all I know, anything else is outside my expertise. It seems like you have a good handle on it though, so good luck.
    – Kyle
    Commented Apr 9, 2013 at 15:22

How would your server know if the URL is coming from the shortening service or not? Couldn't the attacker simply act as if they were the URL shortening service and submit information in a way that would break your system?

I don't see how this is any different from accepting URLs but then doing a URL Rewrite to ensure that the information they passed in on the URL is not displayed, unless I'm missing something about your proposed scenario.

If you are simply using the URL Shortening service to provide random tokens for particular pages to your site, then why not simply store a bookmark internally in your DB. This way you control the input being used to prevent abuse. Even if you are calling the shortening service directly, what would prevent a malicious user from making their own shorted URL for your domain? (Unless you have a shortening service that will only return results from your account.)

  • I think there's a misunderstanding: whatever URL the user sends, that URL first gets send by my webapp to the URL shortening service and then when I'm generating the pages to be served containing the URL the user "inputed", well, I'm not really serving back that URL. I'll only ever be serving URL starting with, say, bit.ly and then adding at most nine alphanumeric characters. I don't care where the URL the user inputs comes from: it shall go through the URL shortening service no matter what and it's the result from the URL shortening service that I shall display on my site. Commented Apr 9, 2013 at 15:37
  • 1
    Ok, in that case, why not simply store your own bookmark codes for pages. Presumably you are having to provide the full URL at some point to the shortening service, why not simply store this information and generate the code yourself and then only allow input of those codes. I'm not seeing what additional advantage an external shortening service is supposed to provide. Commented Apr 9, 2013 at 15:40

You must log in to answer this question.

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