A thorough checklist of top 6 Ruby on Rails Security Best Practices

Ruby on Rails is considered well-balanced and profoundly secure technology for building robust apps with the perfect balance of safety and the right appliance. Of course, Ruby on Rails provides end-to-end encryption, yet there are times when you can find a loophole in the security and increase the chances of a security breach through third-party intruders.

To avoid such an awful situation from happening, I have curated this checklist of the top 6 Ruby on Rails security best practices. That will shed light on the common yet mostly missed opportunities that could give an extra layer of security to your RoR web application.

SO, without further ado, let's get started with the Ruby on Rails best practices that no single RoR Developer should miss out on in 2022.

Top Ruby on Rails security Best practices to watch out in 2022

1. Authentication

For the purpose of Authentication, it is advisable to utilize already existing Ruby Gems like authlogic or devise. And if you are building your authentication process, use the built-in has_secure_password of Rails.

Further, save only the hash of the password without saving the entire thing, and at the time of Authentication, take the hash and compare it with the hash in the database.

The RoR experts of the community also recommend a salt. It is a small random data combined with the password and before it's been through with bcrypt.

2. CSRF- Cross-site Request Forgery

By adding an Authontecity token on forms, Rails protects your app from CSRF. If you do not have the token, you won't be able to submit it to the post-action.

While you use either jquery_ujs or rails-ujs, automatically, the authenticity button will be added. Therefore, Ruby developers won't recommend skipping this step even when you are implementing the ajax actions.

3. Filter passwords and other sensitive data in the log

When the user logs in, the user ID and password is logged in unless you filter the password details RoR creates config/initializers/filter_parameter_logging.rb by default that possess

Rails.application.config.filter_parameters += [:password]

So, the passwords are not saved in clear text, and we do not even need them to appear in the logs to hide the sensitive data.

4. Unauthorized access

This is a basic rule: you should always check the user's authority to make the changes. Suppose you have a page containing the list of projects the user owns, and one of the links might be /projects/1. Now users can shift to any project by doing just /Projects/2 or any other number.

To avoid such things happening use @project = @current_user.projects.find(params[:id]) instead of @project = Project.find(params[:id])

Through such practice, if the project would not belong to the user, it will come to nill if they try to reach out to the other project that does not belong to them.

5. Throttling Requests

There will be many pages requiring you to ask for vital information from your users, for instance, the login page.

You can use Rack attack as a trustworthy middleware that provides throttling, amongst other significant features.

Rack::Attack.throttle('logins/email', :limit => 6, :period => 60.seconds) do |req|

req.params['email'] if req.path == '/login' && req.post?

end

6. No credentials in the Repository

The database credentials, and the important secret key base, and other sensitive data should not be committed to your repository. If your database credentials have been contained by database.yml, they should not be connected to your repository.

config/secrets.yml by default reads such sensitive data and secret key base from the variable in the production environment.

Rails 5.1 has a way to handle and implement the encrypt the secrets. This feature enables the user to commit the encrypted secret file.

Bonus Tip: Certain apps to manage the data provide an admin panel to the super users. Consider this to put it on a different domain name. If your admin panel is distinct from the main web app, apply restrictions like a connection through the VPN or filtering based on IP.

So, here we are, done with all the top Roby on Rails security best practices to secure our RoR app better than ever.

If you find this process complex or even a bit difficult, you can take the professional assistance and Ruby on Rails Developer from one of the trusted resources in the industry and get the optimum advantage of this technology.