Security should be the top priority of every application. Without security, personal information and highly sensitive data will be exposed, extracted and could be used for malicious purposes. A single attack could easily destroy not only the application but everyone related to the application – developers will lose their reputation, clients will lose their customers and customers their personal information and exploited at the hands of online hackers.

Ruby on Rails already have some security measures included in the framework. The security provided however is a little bit limited as the configuration of functions is still left to the developers. Aside from secured coding practices there are certain additions a developer should consider to ensure the security of the application.

Ruby on Rails Common Attacks

Although there are thousands of attacks that could be done in any application, there are notable ones that should be highly considered by Ruby on Rails developers. These forms of attacks are not just simple bugs that could be removed instantly but attacks that will halt the system entirely or jeopardize the security of the user’s information.

CSRF (Cross Site References) – This form of attack looks very innocent from the start. An attacker places a link on the website (usually a form or a blog) and the user will click on the link which will lead to another application. Although this will not hinder the application’s performance, the application became the host of the attack.

XSS (Cross Site Scripting) – Almost the same behavior compared to CSRF but could wreck more damage as the target of Cross Site Scripting is both the user and the website. It will steal the user’s cookies and using it extracts username and passwords or even bypass to fool the system it is the same user.

Caching Tricks – This is the fault of developers who pushed too much caching on the application, the cached data of the user could be stolen to get inside the application

Spamming – Although not as dangerous compared to the previously mentioned attacks, spam posts could destroy the aesthetic portion of the application.

Ruby on Rails Countermeasures Native

Proper use of Post and Get – Post and Get are two of the most common commands used in the Ruby on Rails and other Web 2.0 programming languages. But these functions automatically place the application in security loophole against CSRF. Developers have to properly outline the data that should be associated with these functions.

Using Whitelist – The previously mentioned functions will only protect the application against CSRF but the application will still be susceptible to XSS. To prevent the application from downloading undesirable applications or files, a whitelisting should be implemented. This type of security measure is basically a parameter for the data that should be expected from the URL. By excluding other codes, the online application will still be protected.

File Filters – When the online application requires users to upload or the application will end up downloading data, file filters should be properly implemented. Again, whitelisting should be used to ensure the files are according to specifications. This is different with blacklisting wherein it only prevents what is listed. Whitelisting on the other hand, will only allow files that are listed or according to specifications.

IP Address Limiters – One of the best security measures for Ruby on Rails is to implement IP-assisted access. Aside from requiring authentication, the users can only access the site with their registered IP. This is highly recommended for business purposes to limit number of users.

The Simple Things – Requiring your users to change passwords in a timely manner, restricting password forms to certain characters and implement strict admin changes are only some of the simple countermeasures that developers should never miss out.

Using Plug-Ins

Aside from the tricks in coding you can enforce on Ruby on Rails to improve security, there are a lot of plug-ins specifically developed for Ruby on Rails for security reasons. For example, the plug-in Recaptcha is a security addition to the Ruby on Rails based application wherein the user is required to enter not one but two challenges to prevent bots from accessing the application.

But plug-ins are considered add-ons and are not part of the development process of Ruby on Rails in itself. Before you install the plug-ins, make sure they are updated and also make sure to update them when you make some upgrades in your application.