Learnings from Sqreen’s State of App Sec Report: 70% of Ruby on Rails exploits were SQLi

Saying that digital security is “important” would be the understatement of the century. It’s probably the most crucial aspect of any application nowadays. Unfortunately, security is easy to get wrong, and many developers and organizations do. Count yourself lucky if you never encountered a site that stores passwords in plain text, for instance. 

Developers and organizations must get better at security, and for that, we need education and insights backed by real data. That’s why Sqreen put together its first State of Application Security Report. The report analyzes real data from production applications to obtain insights about security exploits in several languages and on different platforms. Though the report covers several programming languages, this post focuses on the report’s findings about Ruby. You can see the findings on PHP in an earlier post.

We’ll start the post by talking about the report itself. We’ll explain what the report is about, why it was created, and how it was put together. Then, we’ll cover the report’s main findings as they relate to the Ruby language. After that, we’ll share tips and advice on how you can protect yourself from the vulnerabilities you’ve learned about in this post. Finally, we part ways with some final considerations. 

Let’s get started. 

The State of Application Security Report from Sqreen: What’s it all about?

Before we talk about the key Ruby learnings from the State of the Application Security report, it makes sense to share some info on the report itself, so that’s what we’re doing now, in the what-why-how format. 

What is the Sqreen State of App Sec Report?

The 2020 State of Application Security Report is the first security report by Sqreen. To produce the report, Sqreen analyzed many real security exploits over a wide array of programming languages and frameworks and, by doing so, obtained insights about the scenarios more susceptible to the most common security threats to web applications. 

Why does this report exist?

Sqreen released this report was to help organizations better understand their security challenges using actual exploit data rather than self-reported data, which can often be misleading. With the report, organizations can learn about common  security threats their particular tech stacks face using real data. They can also learn the likely causes behind them. Armed with this information, an organization can make smarter decisions about how to allocate resources and fight against those security issues. 

How did Sqreen create the report?

To create the report, Sqreen analyzed anonymized data from real customer environments between June 2018 and July 2020. During that period, more than 6,000 security incidents were discovered across almost 4,000 applications. 

What did the report find out about Ruby apps?

The report analyzed applications written in five languages: PHP, Ruby, Python, Java, and Node.js. While each language faces its own potential threats, and while you should definitely read the sections of the report about the other languages you work with, this post focuses only on Ruby. So, what can we learn about Ruby security from the State of AppSec report? 

The problem: SQL injection is still a top security issue

The OWASP Top Ten still shows that SQL injections are the most common security risk for web applications, and it’s been like that for more than a decade. 

The findings from the report corroborate that claim, showing that SQL injections represent 47% of all security events across the languages analyzed. Yes, SQL injections are still a thing. 

The problem gets worse when we examine Ruby specifically. The report data showed that Ruby apps are particularly susceptible to SQL injections: 70% of them suffered at least an injection attempt. 

You might be wondering why Ruby is at such high risk of SQL injection exploits. Luckily, the report found where the vulnerabilities are located and how they’re initiated. 

ORMs aren’t a silver bullet against SQL injections

As it turns out, writing your apps using a mature and opinionated framework like Ruby on Rails doesn’t completely insulate them from security exploits. It’s particularly interesting and somewhat surprising that coming out of the box with an advanced ORM (in the form of ActiveRecord) doesn’t prevent Rails apps from suffering SQL injection attacks. The report shows that the number of SQL injection attacks to Ruby apps increased by 20% compared to the previous year. 

Most Rails injections happen in the controller

The report found that in 60% of the Rails applications in which a SQL injection incident happened, the vulnerability was living in a controller rather than in other classes, such as helpers. 

Nearly half of incidents happened in admin pages and API endpoints

The report looked further into the issue, trying to uncover why such a high percentage of incidents involved only the controller in Rails. What Sqreen found was that nearly half of all incidents came from API endpoints and the admin page. How is that so? 

It turns out that 26% of injections come from admin pages, while 20% come from endpoints. So, these two sources account for 46% of all SQL injections incidents in the analyzed Ruby apps. 

Why are those problems serious, and what can we do about them?

When it comes to admin accounts, you have to bear in mind that some accounts are powerful. That is, they typically have more privileges and permissions than regular accounts. For malicious individuals, getting hold of such an account is a valuable outcome, making them targets of incredible value. 

And what about endpoints? According to the report, 20% of all Ruby incidents involved API endpoints. That’s a serious problem, especially when you realize that usage of REST and REST-like APIs has been increasing over the last several years, mostly due to the birth and nascent popularity of front-end frameworks such as React, Vue, and Angular. These frameworks are popular because they allow developers to create feature-rich web applications that consume backend APIs. Considering all of that, it becomes clear that ensuring your API endpoints’ safety is one of the most critical security investments you could make. 

So, considering what we’ve learned from the report, what should you do to protect your Ruby/Ruby on Rails apps? 

A key takeaway from Sqreen’s report is that just using a framework—even a mature framework such as Rails—doesn’t make you bulletproof against security problems. It’s necessary to educate developers on efficient ways to prevent SQL injections. It’s then necessary to ensure the framework is used correctly and efficiently in all parts of the application. 

There’s no more online security, just “security”

With each passing year, we live more and more of our lives online. The internet has become our playground, our library, our office, our movie theater, and even our churches and temples. With so many aspects of our daily lives moving to the internet, the lines between the online and the offline worlds are becoming more and more blurry. 

That’s why you can never worry too much about digital security. If you’re a security engineer, educating your developers on your current tech stack’s security challenges should be top of your list. If you’re a developer, educating yourself on this will go a long way. We’ve focused on Ruby apps in today’s post, sharing the (somewhat surprising) main findings from the State of Application Security Report from Sqreen. You know now that most Ruby security exploits were SQL injections. Yes, that’s right. A problem that many in the industry consider solved by this point. 

However, there’s no reason to despair. You’ve also learned that by educating yourself and your coworkers on the efficient ways to use the framework—and then applying that education in practice—it is possible to make your applications more secure. 

To learn more, read the complete report or check out or post on the Sqreen State of App Sec Report Key Takeaways Blog. 

This post was written by Carlos Schults. Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.