Ruby on Rails debuted in 2004, which makes it 16 years old this year. If you plan to build with it or have started the year using Ruby as the core for your web app, it is only natural to check for possible vulnerabilities.

Is Ruby on Rails secure in 2020? The short answer is yes. The framework/language combination has never been more secure than it is today. Nevertheless, we don’t recommend playing fast and loose with it (or any other framework).

This article explains why Ruby on Rails vulnerabilities are only minor security issues and what precautions you can take to be on the safe side.

security blog post bonus

What Makes Ruby on Rails So Reliable

In the case of Ruby on Rails, whether you are just about to start using the framework for your project or have been using it for a while, age is an ultimate advantage. 

The framework has matured for more than a decade. Top companies in a range of markets, from software development to real estate, have been running on Rails since their inception.

Leaders in various industries rely on Ruby on Rails

You’ve probably already used many of the applications that were built with Ruby on Rails: Basecamp, GitHub, Shopify, Airbnb, Twitch, SoundCloud, Hulu, Zendesk, Square, Cookpad, and more. As major players cleave to the framework, they contribute to its further development and improvement of its security.

The latest major vulnerability discovered with the framework dates back to 2012. Egor Homakov, a security researcher, found out he could remotely execute particular tasks, such as committing to master, reopen and close issues in Issue Tracker. The programmer managed to hack GitHub without doing real damage — just to demonstrate that it could be done.

The community had spotted other flaws in the framework throughout the years, but most of them were minor issues that professional RoR developers have been studying until they knew them cold. Since 2016, there haven’t been significant unpleasant discoveries in this area.

The Ruby on Rails community is worth emphasizing as another factor that makes the framework a secure choice. Its official group on Google features 69,201 topics, while Stack Overflow boasts 314,212 relevant questions, many of which are actively discussed.

ror community

All this means that if you encounter a security problem, you can reach out and get help from the community.

Human Element As the Root of All Evil

What is crucial to know about security is that most of the breaches and leaks happen because of the human element.

Negligence, unawareness, and social engineering are the main threats to Ruby on Rails applications. These can threaten your web product at every stage, from its very first day to many years down the track.

We’ve often had to clean up after the original development team who failed to keep an eye on things. Some examples include:

  1. Developers who left the password from the database in the source code. Hackers got hold of the code, extracted the password and stole sensitive business data.
  2. A front-end team who placed the AWS API Access Key in the source code. Perpetrators used the key to tap the company’s cloud infrastructure and launched a Bitcoin mining farm on multiple remote servers. As a result, the business lost a substantial amount of money in a single day.
  3. A DevOps engineer who, after making some changes, forgot to restrict access to the caching database for the outside world. A significant amount of data was stolen through this loophole.
  4. Developers who tend to forget to hide pages from search engines. Some of these pages can contain sensitive information, which is compromised as a result.
  5. Developers who fail to make timely updates to libraries, frameworks, and infrastructure elements; this is also one of the most typical reasons for exposure and undesired consequences.

As you can see, it makes sense to establish mandatory best practices for staff who have access to your website. It’s never too late to do that, but the earlier it’s done, the safer it will be for your company.

Share your story and get a chance to win a prize worth $799

Tell us in the comments what vulnerabilities you have encountered with a Ruby on Rails application and how you managed to fix them. 

A month after this article is published, we will select the three best stories. If yours is one of them, Rubyroid Labs, an award-winning Rails team, will conduct a comprehensive security audit of your website valued at $799, completely free.

Major Ruby on Rails Security Threats

With due diligence, Rails can be one of the safest frameworks to run on. Nonetheless, it is good to know where to look for trouble to ensure peace of mind. 

(And if your product is yet to be developed, you should work towards ensuring its security, because once your web app is online it will immediately become a target for hackers.)

RoR Vulnerabilities Statistics
Ruby on Rails vulnerability statistics according to CVE Details

The most common Ruby on Rails security threats are applicable to all other frameworks as well. The CVE Details website has been tracking vulnerabilities in the framework since 2006. The latest discovered flaws date back to 2017. Let’s take a closer look.

XSS Attacks

Number one in vulnerability statistics for Ruby on Rails is Cross-Site Scripting (XSS) attacks. The attackers exploit XSS vulnerabilities in the code of a trusted website to inject malicious scripts into it.

If a vulnerability of this kind is not fixed, the web application is easily hackable. We once had to clean up for a client after one attacker had entered a specific line of code into the username in his profile. He commented on multiple pages on the website and other users landing there were automatically redirected to his own site.


The second most widespread vulnerability of Ruby on Rails websites is SQL injections (SQLi). If you use a MySQL, Oracle, SQL Server or any other SQL-type database, be warned. The attackers can gain control over the database server behind your web application by executing a malicious SQL statement.

Criminals can use this type of attack to access sensitive data such as personal information of your customers, classified documents, and even passwords from other sources. If you fail to take precautions against SQLi, financial and legal consequences can be devastating.

DoS Attacks

Denial-of-service (DoS) attacks make up about 16% of all threats to Ruby on Rails applications. The attackers can make a resource unavailable to its users by flooding it with a slew of requests that are too heavy for the website to handle.

According to CVE Details, nine DoS vulnerabilities have been detected with Ruby on Rails versions up to 5.0.0.beta1.1 (2016) while the latest framework version, 6.0, arrived on August 15, 2019. This is proof of how important it is to keep up to date.

But you might need a little more than updating. Distributed DoS (DDOS) attacks have lately been a nuisance for many companies that have drawn attention to themselves. We have been able to neutralize multiple distributed DoS (DDOS) attacks with the help of a third-party application.

Bypass Attacks

The fourth most common threat to Ruby on Rails applications that a DevOps should be aware of are the loopholes in the security which allow attackers to get inside. Typically, hackers manage to bypass

  • intended validation steps via crafted parameters (before 5.0.0.beta1)
  • intended change restrictions by manipulating the nested attributes feature (before 5.0.0.beta1)
  • authentication by measuring timing differences (before 5.0.0.beta1)
  • intended database-query restrictions to perform NULL checks or trigger missing WHERE clauses via a crafted request (before 4.0.2)

You can prevent these attacks by establishing a reliable access policy execution process, designing a strong authentication system architecture, and setting strict safety guidelines for developers who work with the application.

General Safety Rules to Prevent a Breach with RoR

There is no one-size-fits-all advice on securing a Ruby on Rails application, regardless of whether it is a simple website or something more advanced, like a custom CRM.

Provide users with a prominent log-out button; use cookies only for the session-relevant data; disallow <script> tags across the website; use a stored timestamp so that your app invalidates old-session cookies; this list can go on and on.

In a more general sense, whether you are about to start developing your application or improving to the security of an existing product, it makes sense to follow these guidelines:


If you manage to hardcode these measures into your security routine early enough, the odds are in your favor.


We hope that this post has managed to convince you that Ruby on Rails is a highly reliable framework in 2020 and years ahead, and that you are better informed of potential threats and appropriate precautions.

If you need to ensure that your application is secure, don’t hesitate: contact us right away.


How useful was this post?

Click on a star to rate it!

Average rating 4.6 / 5. Vote count: 11

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?


CEO at Rubyroid Labs

Write A Comment