70+ Ruby on Rails Security Best Practices & Vulnerabilities

If you are looking for the cover to cover tutorial on Ruby on Rails Security Best Practices, you have come to the right place.

In this comprehensive guide, I describe:

• What's in Ruby on Rails out of the box security-wise
• How to secure HTTP requests
• Common security vulnerabilities in the authentication flow
• Sane guide to the authorization implementation
• Automation of security audits using open-sourced solutions
• Available security monitoring services overview
• and a lot more

So if you are looking to join the club of those who are better safe than sorry in their secure Ruby on Rails development, read on.

Let's dive neck-deep into the Ruby on Rails security world.

Ruby on Rails Out Of The Box Security Measures

Ruby on Rails, among the other highly popular, open-sourced software development frameworks such as Django or Laravel, is said to be highly secure.

There are quite a few reasons that make this statement true

• thousands of people work with Ruby on Rails every day
• hundreds of people try to breach Ruby on Rails every day
• maintainers implement a strict security policy

Addressing the last point, Ruby on Rails takes web security as serious as it gets - to the point where you can make money improving it.

Ruby on Rails Security Bounties on HackerOne

Let's now see through the Ruby on Rails process on dealing with security vulnerabilities.

Ruby on Rails Security Policy

The way Ruby on Rails team has it covered leaves nothing to a chance, here's the short outline:

• reported vulnerability is discussed via private channels
• if confirmed, all the code is checked for similar vulnerabilities
• fixes cover all the supported releases, not only the latest one
• interested parties get notified along with the launch
• they wait an additional 6 hours before the announcement

Here's the first step to ensure the security of your Ruby on Rails application.

The best way to receive all the security announcements is to subscribe to the Rails Security mailing list. The mailing list is very low traffic, and it receives the public notifications the moment the embargo is lifted.

Ruby on Rails "Security Policy"

After visiting the provided link, simply Join the group as you can see below

Ruby on Rails Security Google Group

With this simple thing in place, you can rest assured that information on any security vulnerability in the Ruby on Rails itself will be sent to you as soon as it is fixed.

It is especially worth keeping an eye on this list every time Ruby on Rails releases the new mayor version, as that's when big changes occur in the framework's core itself.

Big changes come with big risks, and as you can see on the screenshot above, the most recent security vulnerability in Ruby on Rails was patched not so long ago, on March 19th - which is almost a year after the initial Ruby on Rails 6.0.0 stable release.

Ruby on Rails Built-in Security Measures

Ruby on Rails has been around the block for quite a while - since April 2008 - and has seen its fair share of security vulnerabilities.

Being maintained by very responsible people, it implements a whole lot of security measures out of the box to prevent developers from making mistakes.

Ruby on Rails Security HTTP Headers

At this point, you have most likely heard about the HTTP security headers.

Let's see what headers does Ruby on Rails equip each request with by default.

Those settings belong to the underlying ActionDispatch module, a huge part of the Rails core, responsible for routing the requests to controllers.

lib/action_dispatch/railtie.rb

config.action_dispatch.default_headers = {
  "X-Frame-Options" => "SAMEORIGIN",
  "X-XSS-Protection" => "1; mode=block",
  "X-Content-Type-Options" => "nosniff",
  "X-Download-Options" => "noopen",
  "X-Permitted-Cross-Domain-Policies" => "none",
  "Referrer-Policy" => "strict-origin-when-cross-origin"
}

There's a bunch, provided settings ensure some security measures that in most cases don't need tampering with.

If you do need to change them, it's doable in either config/application.rb or dedicated environment configuration files.

Do notice, that this way you can add any header you'd like to your requests.

Let's now see what are those responsible for exactly.

Ruby on Rails X-Frame-Options Security Header

X-Frame-Options header with a secure SAMEORIGIN value instructs the web browser that it should only open URL addresses linking to the same domain in the <iframe /> tags.

Ruby on Rails X-XSS-Protection Security Header

X-XSS-Protection with value 1; mode=block enables the built-in Cross-Site Scripting filter. The first part, 1, simply turns the option on.

In the second part, mode=block prevents browsers from rendering pages if a potential XSS reflection attack is detected.

Ruby on Rails X-Content-Type-Options Security Header

X-Content-Type-Options with value nosniff is responsible for blocking a request if its destination is of either style or script types and their MIMIE types do not match.

Ruby on Rails X-Download-Options Security Header

X-Download-Options is a header specific to Internet Explorer 8. Its functionality is to block the browser from executing the downloaded HTML file in the context of the website.

Ruby on Rails X-Permitted-Cross-Domain-Policies Security Header

X-Permitted-Cross-Domain-Policies with value none instructs clients such as AdobeAcrobat and Flash to avoid accessing any data from your domain.

Ruby on Rails Referrer-Policy Security Header

Referrer-Policy is responsible for controlling how much information should be sent in the Referrer header. The strict-origin-when-cross-origin value:

• allows sending origin, path and query string for the same origin requests,
• allows sending only the origin performing the cross-origin requests, as long as protocol security stays the same
• does not send Referrer header to less-secure destinations

Now that we've met the defaults, let's see what else is there.

Ruby on Rails Content-Security-Policy Security Header

On top of setting the sane defaults for us, Ruby on Rails covers yet another security header, called Content Security Policy.

Content Security Policy (CSP) is an HTTP response header that restricts the browser to loading external assets such as scripts, styles or media from a wide variety of sources — as well as inline scripts.

sqreen.com

As usual, a well-known at this point configuration DSL allows us to configure it globally

config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy do |policy|
  policy.default_src :self, :https
  policy.font_src    :self, :https, :data
  policy.img_src     :self, :https, :data
  policy.object_src  :none
  policy.script_src  :self, :https
  policy.style_src   :self, :https
  policy.report_uri '/csp-violated'
end

Rails.application.config.content_security_policy_report_only = false

as well as a per-controller basis, using the content_security_policy block

Ruby on Rails Feature-Policy Security Header

Feature-Policy header is another security header that Ruby on Rails let us configure, despite still being in the experimental state.

The Feature-Policy  header is still in an experimental state, and is subject to change at any time. Be wary of this when implementing Feature Policy on your website.

MDN "Feature-Policy"

Its code in the ActionDispatch module is very similar to the CSP one, and the header can be configured in the same manner

Rails.application.config.feature_policy do |policy|
  policy.fullscreen :fullscreen
  policy.geolocation :geolocation
  policy.gyroscope :gyroscope
end

There's also a link to the full list of available features in the Ruby on Rails source code.

I guess Ruby on Rails does not document it yet in their official guides because the header is still experimental.

Ruby on Rails SQL Injection Prevention

One of the most frequently occurring attacks, both in Ruby on Rails and in the web development in general, is SQL Injection.

XKCD SQL Injection Classic Exploits of a Mom

Ruby on Rails does not fully prevent it yet still equips its ActiveRecord ORM in methods that allow you to write the code that's impossible to carry on the SQL Injection attack.

There's a great resource on the subject, the Rails SQLI

This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. Careless use of these methods can open up code to SQL Injection rails-sqli.org

And it is full of easy to understand examples of how the attack can be carried out.

It is good to take a moment to review them but worry not - there are tools further down this tutorial that audit your Ruby on Rails code in the SQL Injection context.

Ruby on Rails Data Sanitization

There are multiple different attacks that can be carried out via the Ruby on Rails View layer.

That said, Ruby on Rails comes prepared for those security vulnerabilities, with its awesome ActionView::Helpers::SanitizeHelper module, that in total exposes four different methods that allow you to render anything safely.

Those are:

• sanitize
• sanitize_css
• strip_links
• strip_tags

With the sanitize being the most used one

Sanitizes HTML input, stripping all but known-safe tags and attributes. It also strips href / src attributes with unsafe protocols like javascript:, while also protecting against attempts to use Unicode, ASCII, and hex character references to work around these protocol filters. All special characters will be escaped.

Sanitize Helper documentation

Whenever you render anything that is submitted to your Ruby on Rails application via users, such as for example comments, remember to sanitize it via dedicated helper provided in the framework.

Ruby on Rails Cross-Site Request Forgery

That's the one that's prevented by Ruby on Rails fully out of the box if you follow its conventions, but let's see what it actually means.

Here's how the attack happens:

• Hacker links to your application on his website, by for example placing the malicious link in the <img src="http://myrails.com/resource/1/destroy" height=0 width=0 />
• Hacker's website visitor executes the code that otherwise requires authorization - as long as his session on myrails.com did not expire.

With Rails' default CSRF tokens in place, nothing gets executed. Those tokens are sent from the frontend to the backend layer with every form submission.

If they don't match the expected ones's the request fails. Simple, yet effective.

Ruby on Rails Sessions Security

Ruby on Rails comes super-prepared for securing the users' sessions and covers it in great detail in its Security Guide

They have a dedicated chapter on how to properly configure and manage sessions, that cover:

• Session Hijacking prevention
• Secure Session Storage
• Configuring rotation of Encrypted and Signed Cookies
• Replay Attacks for CookieStore Sessions
• Session Fixation explanation and countermeasures
• Session Expiration management

There's a lot happening out of the box, but whenever configuring it, use the official guidelines as your implementation reference, as those attacks are super-dangerous.

Ruby on Rails HTTPS Configuration

One thing that goes without saying in the present state of the Internet, the same as it should in the secure Ruby on Rails application, is the secure HTTP protocol, HTTPS.

It, for good reasons, became so popular, that there are multiple trusted providers with whom you can simply obtain the SSL Certificate completely for free - such as for example Let's Encrypt.

Once you do that, setting up the Ruby on Rails to use the secure HTTPS protocol is as easy as it gets.

config/environments/production.rb

Rails.application.configure do
  # other config
  config.force_ssl = true
end

With this single line of code in place, you get:

• Cookies flagged as Secure
• HTTP Strict Transport Security (HSTS) header that instructs the browser to perform subsequent requests via HTTPS only
• Redirects all requests to the HTTPS

In most cases, excluding internal services communication, this is a very much desired behavior in the secure Ruby on Rails application.

Ruby on Rails Secure Users Authentication

Now that we have reviewed what comes security-wise out of the box in Ruby on Rails, let us see what does not, yet is still universally implementable for almost any web application.

One such thing is the users' authentication.

Authentication is the act of proving an assertion, such as the identity of a computer system user.

wikipedia.org

Nowadays most of the web applications provide a way for anybody to sign up to them, and in turn, become him or herself in its domain.

Here's where the hard part comes.

As opposed to the real world where we can physically look at somebody at the counter, in the virtual world it is very easy to impersonate someone else and do something more or less harmful on his or her behalf.

Here's where the Ruby on Rails authentication security comes into play.

If you are looking for a short answer to this massive subject, it breaks down to one simple advice.

Despite what they say, do use Devise.

If you are building your first Rails application, we recommend you do not use Devise. Devise README.md

Yes, it is good to understand all that happens under the hood, but learning by doing beats implementing it yourself.

However, if you are working on a solution that is supposed to work on an actual production environment, it is good to start with some other resources first, in order to fully understand the complex authentication process

• Read The definitive guide to form-based website authentication
• Follow Michale Hartl's tutorial on Modeling Users
• Complete the Codecademy's Ruby on Rails Authentication and Authorization tutorial

Take your time, visit those links.

This will hopefully make you understand how complex is the process of implementing the authentication in general, as well as in Ruby on Rails.

If you are a junior developer who has just started a new job and got the task of implementing the authentication all by yourself, start looking for a new one.

If you are a senior developer looking for a resource to send for a junior developer tasked by you to implement the authentication all by himself, please, change the industry.

I mean it.

With those first two high-level security measures in place, let's move on to those that you can implement in the actual code.

Ruby on Rails has_secure_password

One of the measures that are a must-have for Ruby on Rails secure user authentication is not storing an actual password in the database.

With help comes the ActiveModel::Validations#has_secure_password.

Adds methods to set and authenticate against a BCrypt password. This mechanism requires you to have a XXX_digest attribute. Where XXX is the attribute name of your desired password.

ActiveModel::Validations#has_secure_password documentation

It requires the bcrypt gem to work and as you can see an additional database column for whatever AR model you want to authenticate.

bcrypt() is a sophisticated and secure hash algorithm designed by The OpenBSD project for hashing passwords. The bcrypt Ruby gem provides a simple wrapper for safely handling passwords.

rubygems.org bcrypt

As often in Ruby on Rails, a semi-complex problem is easily solved with a single line of code.

Ruby on Rails Secure Devise Authentication

The most popular choice for handling a complex Ruby on Rails authentication process in a secure manner is the aforementioned Devise gem.

Ruby on Rails secure Devise authentication

Devise is a very sophisticated solution that is composed of ten modules. You can pick and choose those that fit your use-case.

Let's focus on those that are designed to increase the security of your Ruby on Rails application.

The first module, Trackable, is responsible for tracking all the sign-in activity.

In case of any security breach, this information can help you or even your users to review if their latest activity in your Ruby on Rails application was, in fact, theirs, and not someone else's.

The next super important module that helps to prevent impersonating users of your Ruby on Rails application is called Timeoutable and it handles sessions expiration time.

The last one, Lockable, allows us to lock an account after a given amount of unsuccessful login attempts. It is later possible to unlock it via an email, or after a specified time period.

On top of those, you can extend the default Devise behavior via the dedicated initializer.

config/initializers/devise.rb

Devise.setup do |config|
  config.send_email_changed_notification = true
  config.send_password_change_notification = true
end

This way users of your Ruby on Rails application get notified anytime their account's email or password is changed.

If you want to be super equipped for debugging of potential security breaches, you can consider using [AuthTrail](https://github.com/ankane/authtrail) on top of Trackable.

This gem creates a new ActiveRecord model, called LoginActivity, that describes in a great detail every login attempt via your Ruby on Rails application users.

Having it in place, you can achieve functionality similar to this one provided by Google, among many

Google Login History

This gives your users an overview of their login history, which can potentially alert them on any unexpected activity on their accounts.

One last thing worth considering for an even more increased users' account security is using the CAPTCHAs.

reCAPTCHA human verification

It is an effective mechanism that helps to determine if any of the requests are generated by a bot or a human.

As usual in the Ruby world, there is a ready to use solution, a ReCaptcha gem, that integrates nicely with the Devise, as described here.

Ruby on Rails Devise Alternatives

Devise gem is not the only one available for authentication in the Ruby on Rails world, yet it is truly the most popular one.

That said, it is worth checking out what alternatives for safe and secure authentication options an open-sourced world gives us for the Ruby on Rails framework.

In order to not repeat something that's already doing a great job with comparing those libraries, I encourage you to visit the Awesome Ruby Devise alternatives listing.

There is a total of 15 solutions for the secure Ruby on Rails authentication and users' accounts management.

Ruby on Rails Authorization and Access Control

Before we get to the matter of secure Ruby on Rails authorization techniques, it is important to understand the difference between Authentication and Authorization.

• Authentication checks if users are in fact who they claim they are.
• Authorization checks if the authenticated user has permission to perform specific actions.

Let's have some examples of the authorization:

• User can up or downvote once - StackOverflow
• Visitors can clap the maximum of 50 times per article - Medium
• People over 18 years old can vote for president - Poland

Those are simple, high-level examples of entities being authorized to perform actions in the defined domains.

Ruby on Rails authorization security vulnerabilities might cause

• leakage of sensitive information
• abuse of privileges
• data tampering

Those are potentially very, very dangerous for your business and for any system in general.

In order to keep it extra safe, the common security measures worth having in place for a good authorization system are:

• first and foremost, access to system-level resources should be restricted
• do not rely on a single authorization gatekeeper, as it might fail
• store the authorization in the database in a proper, secure manner

That said, as usually in the so-far secure Rails world, there are ready to use, battle-tested solutions to get the job done.

Ruby on Rails Pundit Authorization Management

The most popular authorization solution for a secure Ruby on Rails is a Pundit gem

Pundit provides a set of helpers which guide you in leveraging regular Ruby classes and object oriented design patterns to build a simple, robust and scalable authorization system.

Pundit README.md

It uses simple Ruby objects, called Policies, that reside in the app/policies directory of your Ruby on Rails application.

PolicyObjects names strictly correlate with ActiveRecord models, which makes the whole approach super simple and easy to understand.

Ruby on Rails CanCanCan Authorization Management

The second most popular solution for secure management of the authorization flow in the Ruby on Rails is a CanCanCan gem

CanCanCan is an authorization library for Ruby and Ruby on Rails which restricts what resources a given user is allowed to access. All permissions can be defined in one or multiple ability files and not duplicated across controllers, views, and database queries, keeping your permissions logic in one place for easy maintenance and testing.

CanCan README.md

It equips Ruby on Rails application with a special DSL that mostly based on, you guessed it, the "can" word.

Basically, you define Ability classes that define the access and can use super-simple helpers in your views, controllers and other classes via new ActiveRecord models methods.

Ruby on Rails Authorization Best Practices

Let us take a quick look at the high-level authorization best practices in Ruby on Rails.

• Do not ever leave any backdoors
• Follow the "least privileged" authorization model.
• The less user can do by default, the better
• Crucial data modification should be permitted explicitly
• Understand the difference between coarse-grained and fine-grained authorization

Before putting the work into implementing the secure authorization system of the next Ruby on Rails application, make sure you fully understand those.

Ruby on Rails API Security

Ruby on Rails API security involves whatever's applicable from other parts of this article, with one addition - the authentication part.

In most cases, API authentication in the Ruby on Rails is token-based, which is an alternative to the session-based method.

Token-based authentication is stateless - it does not store anything on the server but creates a unique encoded token that gets checked every time a request is made.

"Token-based Authentication with Ruby on Rails 5 API" by Hristo Georgiev

It only makes sense to use this kind of solution, as standalone Ruby on Rails API does not necessarily create a session for various users.

The most popular solution for the token-based authentication in Ruby on Rails APIs and in general is JWT, standing for JSON Web Token.

JSON Web Token is an open standard - RFC 7519 - that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

jwt.io

Implementing JWT in Ruby on Rails is as easy as it gets, and there's a dedicated jwt gem for doing just that.

Ruby on Rails Request Blocking and Throttling

One common approach to preventing security breaches such as the Brute-Forcing Accounts attack is implementing the request throttling and blockage approach.

As usual in the Ruby on Rails world, there is a ready to use solution to do just that, the RackAttack gem.

Protect your Rails and Rack apps from bad clients. Rack::Attack lets you easily decide when to allow, block and throttle based on properties of the request.

Rack::Attack README.md

It is a drop-in solution for Ruby on Rails applications, enabled by default after the gem installation.

We are able to customize its setting via dedicated config/initializers/rack_attack.rb initializer.

The repository hosts some ready to use configuration solutions for real-world problems, such as

• Throttling spammy clients
• Allow a fixed amount of requests per minute for all IP addresses
• Throttle requests to a specific endpoint

Rack::Attack is a middleware that is especially worth using in the Ruby on Rails applications that do not implement those security measures on the lower level, such as NGINX for example.

Ruby on Rails Security Audit Gems

We have some perspective on the Ruby on Rails Security Best Practices at this point.

I believe that at some point you've already encountered some of the security vulnerabilities and measurements mentioned in this article.

Keeping all of them constantly in mind is not an easy task to do, and depending on programmers memory alone is yet another security vulnerability, known as The Human Error.

Thankfully, there are measures to prevent it.

Let's see what automated audits for scanning the Ruby on Rails security are there.

Ruby on Rails Brakeman Security Audit Gems

The most popular community choice for auditing Ruby on Rails application against security vulnerabilities is the Brakeman gem.

Its maintainers are also authors of the Rails SQL Injection Examples website mentioned before.

Brakeman usage is as simple as executing the bundle exec brakeman command in the root of any Ruby on Rails application.

This is especially useful for hooking into the Continuous Integration suite. If you're interested in doing so, you can see how it's done in our Ruby on Rails tutorials:

• Ruby on Rails with Brakeman on CircleCI
• Ruby on Rails with Brakeman on GitlabCI

However, there's more to it.

Brakeman by default does not run all the audits available, there are deliberately skipped, optional checks.

bundle exec brakeman --run-all-checks --rails6

If you find this version of the command too restrictive, or not really applicable to your use-case, use --no-exit-on-warn flag additionally in the CI instead of turning the --run-all-checks off.

This can be even further customized using the exact checks we want to run to the command in the dedicated configuration file.

Ruby on Rails Dawnscanner Security Audit

The second quite popular choice for Ruby on Rails security audit is the Dawnscanner gem.

Dawnscanner is a source code scanner designed to review your ruby code for security issues.

Dawnscanner README.md

Unfortunately at this point, the project is on hold and my mentioning it here is more for you to keep an eye on than to actually implement it in your Ruby on Rails projects.

It still does work, has a 100% code coverage and overall seems like a solid solution - I have tested it on some small-to-medium Ruby on Rails projects.

From the security perspective though, it might not be the best idea to use the unmaintained gem.

Nevertheless, keep your ear to the ground for the Dawnscanner gem, as it has a very promising base of security audits, that is tightly coupled with the Common Vulnerabilities Enumeration - you can see the planned work in the gem's repository issues.

Ruby on Rails Bundler-Audit

While the tools such as Brakeman and Dawscanner audit your Ruby on Rails code against any security vulnerabilities, the bundler-audit gem checks all the 3rd-party gems bundled into the Gemfile.lock.

In most cases, it should be used in the Continuous Integration suite without returning any error code and mostly as a context on the current situation, as otherwise, your jobs might start to fail unexpectedly.

The one thing worth keeping in mind with this one is to check for its updates, as it uses the second gem of the same maintainer, called Ruby Advisory DB.

In order to keep your 3rd parties' security scans up to date, keep the Bundler Audit gem up to date as well.

Ruby on Rails RuboCop Security Department

One last static code analysis tool that takes security into consideration is the most popular Ruby code listing tool, RuboCop.

In its core gem, it has a dedicated Security department with a modest number of 5 cops.

Don't be put off by this small amount though, as in total, with all its extensions hooked-up RuboCop can make your code potentially 1.5k times better

• and better the code, better the security, too.

Read more about Ruby on Rails RuboCop configuration tutorial Ruby on Rails RuboCop configuration tutorial</a>.

Ruby on Rails Security Audit Services

If you don't feel like hooking up all the security audits in the Continuous Integration suite yourself, you can always subscribe to the ready-to-use solutions.

Security Audits in the GitHub Marketplace

There's a good chance that you host your repository on Github, and if that's the case, the Github Marketplace has at this point a total of 112 solutions tagged as Security.

Eight of those are marked as Verified by GitHub.

GitHub Marketplace Security Solutions

Six of them are free to use:

• Dependabot Preview
• Snyk
• LGTM
• Sonatype DepShield
• WhiteSource Renovate
• WhiteSource Bolt

Another one of the eight, BackHub, serves the sole purpose of the repository backup and its pricing starts from $12 / month for 10 repositories.

That leaves us with the last one, GuardRails, that despite its name supports not only Ruby on Rails security audits but a total of 10 programming languages.

It has 3 paid plans

• $1 / month for 3 private repositories
• $45 / month for 5 private repositories
• $230 / month for 25 private repositories

This is only an overview, as those plans vary in other aspects such as for example queue priority.

DevSecOps Security on GitLab

The second most popular choice for hosting the code worldwide is GitLab, and it offers its custom security solution called DevSecOps

GitLab DevSecOps

This full-blown security audit solution was announced at the end of June 2019.

DevSecOps integrates security controls and best practices in the DevOps workflow. DevSecOps automates security and compliance workflows to create an adaptable process for your development and security teams.

GitLab answering "What is DevSecOps?" question

Do remember that GitLab itself uses Ruby on Rails internally, which means that their offer comes prepared exactly for this use-case.

Hakiri Secure Ruby Apps Shipment

The last option worth mentioning is Hakiri Hakiri</a>, a standalone security audit solution fully dedicated to Ruby.

Ruby on Rails Security Audit with Hakiri

That makes it also a great choice for auditing the security of Ruby on Rails projects.

Hakiri monitors Ruby apps for dependency and code security vulnerabilities. hakiri.io

It breaks down to three functionalities:

• Reporting vulnerabilities in gems
• Finding security holes in the code
• Announcing new vulnerabilities

Hakiri's pricing starts from $19.99 and goes up to $99.99 per month, depending on how many private repositories and people with access to the dashboard you need.

It integrates with GitHub out of the box and offers a 14-day free trial.

Sqreen Application Security Management

One of the most complex security solutions for Ruby on Rails applications is Sqreen Sqreen</a>.

Sqreen Application Security Management

Sqreen gives its users a real-time security monitoring dashboard. This is quite a unique approach, and the expensive one too - their Lite plan costs $499 per month.

Security built into every app. Everywhere.

sqreen.com

On top of that, they offer the Free starter plan for a single production application, under one condition - you have to display its badge on your website.

This is a great starting point for anybody interested in a full-blown, dedicated and a very complex solution to the Ruby on Rails security monitoring.

Hix Security Approach

The most security vulnerabilities in Ruby on Rails applications occur as a consequence of human error.

Hix is a solution that allows you to eliminate the possibility to make one at the earliest stages of the Ruby on Rails application lifespan - during its first initialization.

From its first release, Hix:

• Sets up Brakeman in the CI suite
• Sets up RuboCop with full Security Department in the CI suite
• Sets up Errors and Exceptions monitoring via dedicated SaaS services

And those are just to start with, as there is much more coming, with this article serving as a guide for the further implementation in the package.

I cannot stress enough how big of an advantage is having Brakeman hooked up into the Continuous Integration suite or monitoring the errors and exceptions via a dedicated SaaS since the first commit.

On top of that, a whole lot of configuration that Hix starts every new Ruby on Rails project with is carefully tested.

If you care about the Ruby on Rails security, eliminate the human error from the earliest stages by using Hix.

Conclusion

As you most likely realize by now, security in Ruby on Rails and in general is not a piece of cake.

Despite Ruby on Rails implementing a lot of security measures out of the box, a responsible developer always keeps it in mind, especially when implementing solutions to problems related to sensitive data.

Thankfully, there are multiple open-sourced and paid solutions that serve the sole purpose of keeping the Ruby on Rails security in check automatically.

What is your take on Ruby on Rails Security Best Practices?

Please let me know in the comments!