# Security question : making urls safe **URL:** \ **Category:** Rails\ **Created:** [March 25, 2009, 12:05am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795 "2009-03-25T00:05:02Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 12:05am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/1 "2009-03-25T00:05:02Z")
Hi folks, Is there an issue with urls and security? How should I be encoding them? More than just h()? thanks ---
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 12:52am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/2 "2009-03-25T00:52:28Z")
I’ve read hundreds of these guides: they tell you to encode but usually not how in differing circmstances. The rails docs aren’t well cross referenced, so they are out also. That’s why I am asking in a newsgroup. Do you know the answer? ---
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 12:23am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/3 "2009-03-25T00:23:46Z")
On Tue, Mar 24, 2009 at 6:04 PM, itsastickup [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Is there an issue with urls and security? How should I be encoding > them? More than just h()? > **[Securing Rails Applications — Ruby on Rails Guides](https://guides.rubyonrails.org/security.html)** > > Securing Rails ApplicationsThis manual describes common security problems in web applications and how to avoid them with Rails.After reading this guide, you will know: All countermeasures that are highlighted. The concept of sessions in Rails, what... – Greg D. [http://destiney.com/](http://destiney.com/) ---
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 11:06am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/4 "2009-03-25T11:06:25Z")
Ok, thanks for that. Here’s an example of what I mean: I want to let the user click a user provided url. That url could be composed of javascript. I am asusming h() won’t help for this situation. Is my only option whitelisting? If whitelisting is it then I would prefer not to trust myself to the (rather fragile) url Regex’s out there. How do I know they won’t leak? These security guides often don’t tell how, just that you must. And there is no standardised library that I know of. On 25 Mar, 00:48, Robert W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 1:48am UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/5 "2009-03-25T01:48:07Z")
itsastickup wrote: > Is there an issue with urls and security? How should I be encoding > them? More than just h()? Firstly h() doesn’t encode URLs. Secondly URL encoding is not about security. URL encoding is used to convert characters in a URL to those of the limited set of characters that are valid for URLs. See: [HTML URL Encoding Reference](http://www.w3schools.com/TAGS/ref_urlencode.asp) The Rails security guide posted by Greg contains the information you need to know to secure your Rails application. If you’re querying about the security of the transmission of data between the client user agent (browser) and the web server, this is provided by the SSL/TLS protocol. SSL/TLS is common to all web sites and applications that need to protect the transmission of data across the internet, whether they be Rails or static web pages. SSL/TLS is also used to protect against so called “man-in-the-middle” attacks. SSL/TLS (as far as we know) makes it impossible for one web server to “spoof” a legitimate server. The fake site should never be able to acquire a valid certificate for a different domain. Beyond that, there are also be security concerns in the client web browsers themselves. But, that’s not really your concern as an application developer. That is unless you’re the one trying to hack into client machines though security vulnerabilities in client browsers, but I trust that you’re not. ---
**Author:** ![itsastickup](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/7feea3/32.png) [@itsastickup](https://www.ruby-forum.com/u/itsastickup)\ **Post date:** [March 25, 2009, 12:58pm UTC](https://www.ruby-forum.com/t/security-question-making-urls-safe/163795/6 "2009-03-25T12:58:50Z")
itsastickup wrote: > Ok, thanks for that. > > Here’s an example of what I mean: > > I want to let the user click a user provided url. That url could be > composed of javascript. I am asusming h() won’t help for this > situation. Is my only option whitelisting? > > If whitelisting is it then I would prefer not to trust myself to the > (rather fragile) url Regex’s out there. How do I know they won’t leak? > These security guides often don’t tell how, just that you must. And > there is no standardised library that I know of. Thanks for this further explanation. What you are describing is a little different than what I understood from the OP. Basic rule of thumb is “Never trust ANY user input!” This is especially true if you are accepting URL’s from users. In this case since you are taking a URL as an input parameter from the user then you certainly should sanitize that input using html\_escape (i.e. h) method when outputting the value. It might even be safer in this case to sanitize the input value before saving it to the database or other persistent storage. This should ensure that any attempt to inject JavaScript, or other unsafe user input, get treated as literal text.