Security management is a major skill that software developers need to master. In days past, it’s security scientists or cryptologists who worried about such things. However, because of the ever-increasing instances of data breaches, firewall failures, and so on, security is being embedded into every fiber of the software development lifecycle.
While security isn’t limited to specific programming languages, this article will discuss some best practices that Ruby developers can incorporate into their workflow. Most points in this list are in the context of Ruby on Rails—the most popular framework using the Ruby language. However, these points can be applied to projects using other Ruby frameworks or even projects not using any framework at all.
Don’t hardcode secrets or credentials into your codebase
Often, developers forget to hide credentials or secrets from their codebase. For instance, when first writing the code, it’s fine to hard code them to, say, test the connection to a third-party API or test the connection to different databases.
The problem is when such secrets and credentials are left in the code and committed to the remote repository.
To remedy this, configuration files can be used. Such configuration files shouldn’t be committed to the remote repo. The production environment will have to have its own copy of this file. It should only be visible to those who have access to the production environment settings. To add an extra layer of security, one can also make use of Ruby on Rails’ built-in credentials.
Validate user inputs
SQL injections make up 70% of all Ruby on Rails attacks. Attackers of this sort take advantage of some code flaws to inject SQL statements into user inputs. Such statements can be something that queries the database for all user account numbers or other sensitive information.
Of course, these code flaws should be avoided. But often, developers fail to validate user inputs. Thus, attackers can easily type in scripts into form fields. Therefore, it’s a must that any field where a user inputs data should have validation rules. To prevent SQL attacks (or even cross-site scripting attacks), one can use regular expressions to block any SQL script-like inputs.
Use proven gems for authentication
During authentication, it’s very important to convert passwords into non-readable texts. It may be in the form of encryption or hashing. In both cases, the algorithm being used is very crucial. A weak encryption mechanism can result in passwords being easily stolen (through SQL injection attacks or session hijacking).
While developers can roll out their own encryption/hashing mechanism, there are already widely used gems that can get the job done, such as bcrypt.
Having said that, one may also experiment with other authentication libraries. But, be sure that the developer community has vetted the library.
Debugging probably is one of the most useful skills a software engineer should master. It’s an art as well as a science. A well-versed debugger will easily pinpoint issues in code such that those issues won’t reach the end-user of the application. This goes for security vulnerabilities in code too.
However, debugging can be very painstaking. Most of the time, bugs or vulnerabilities aren’t apparent until one digs very deep into several lines of code in several files. This is where debug plugins come into play. Gems such as ruby-debug-ide and ruby solargraph are very powerful tools to consider. These tools give you x-ray vision and let you see every single detail of your code and its execution.
Install security tools into your project
Sometimes, no matter how well you incorporate the other items in this list, defects and vulnerabilities can still escape you. Especially when using open source libraries, security issues are hard to detect (until an attack happens). For this reason, it’s vital to take advantage of security tools that you can install in your repository. These tools do an intermediate check into the code before any pull request and build can succeed.
There are lots of such tools. Personally, I am partial to WhiteSource Diffend. It is a free tool that detects, blocks, and protects open source users against software supply chain risks. It also has a user-friendly dashboard so it’s easy to learn. Installing it on your project isn’t a single step, but WhiteSource provides easy-to-follow documentation for this.
Diffend performs automatic reviews, informs you of any changes made in the project, and tells you whenever something requires your attention.
Overall, tools such as Diffend ensure that no bug or vulnerability ever gets pushed into production. This is very important as new vulnerabilities appear daily. Manual detection may not be feasible, let alone probable.
Always update your dependencies
This doesn’t require a lot of explanation. As attackers and cyber-criminals invent new ways of exploiting vulnerabilities, open source packages need to keep updating themselves to thwart such attacks. So, any library you are currently using needs to always get updated to the latest stable version to get all the patches from their developers.
Write logs, especially for data-sensitive operations
User logs can be very helpful when identifying potential attack surfaces. Logs also help in investigations during actual attacks. For example, you can include information relating to failed login attempts and user IP addresses in your logs.
As we have seen here, security practices are not difficult to incorporate. It’s just a matter of having them on your and your team’s agenda. Implementing some simple security protocols and habits can go a long way in making your application safer and more trustworthy.