Security Is Not an Afterthought

Secure Development with Ruby on Rails

07 Mar 2017 - - by Daniel Jonasson

Security Is Not an Afterthought

Secure Development with Ruby on Rails

07 Mar 2017 - - by Daniel Jonasson

Anyone that has opened a newspaper in the last few years will be well aware of the security breaches that happen on a regular basis. Google, Yahoo, Facebook, Dropbox and LinkedIn are just a few of the big names that have suffered attacks where hundreds of millions (yes, hundreds of MILLIONS!) of passwords and, sometimes, personal information have ended up in the wrong hands.

For many years, security in application design and development has often been left up to either vigilant developers taking it upon themselves to produce quality code or to security reviews at the end of the development process (often with difficult and/or costly refactorings as a result).

This approach could work well in theory, but in practice rarely does. It is unlikely that every developer involved in a project know about every security concern. This is only natural and particularly so in computer security where new attack methods pop up on a regular basis. Even the most seasoned security analyst will never tell you that an application is 100% secure – we cannot know what we do not know.

With these considerations in mind we can easily see that any help we can get from the tools we use during development is extremely helpful. This is one of many reasons why we like to work with the Ruby on Rails framework. Any framework or any programming language can produce software with or without security flaws. What really sets Rails apart though is that good design, intelligent defaults, best practices, and an emphasis on security “out of the box” make it easier to do the “right thing”. In this article we will go over a few of the things that we think make Rails a good alternative for developing secure applications.

Security Needs to Be a Part of Development

Developing using Rails we get a lot of security features for free using the generators provided and the defaults established by the framework itself. Unless we actively do something to deactivate it we have CSRF (Cross-Site Request Forgery) protection, encrypted cookies, session fixation protection, strong parameters, automatic filtering of sensitive data from logs, etc. Rails also makes it easy to avoid other types of attacks such as XSS (Cross-Site Scripting) and SQL injection by providing simple, standard ways of doing what needs to be done.

In addition to the security features of the framework itself we have a whole host of options when it comes to libraries adding security features to our applications or helping us test for weaknesses. Typically these libraries focus on doing one thing and doing it well. By using them in our development we can benefit from the expertise of others that may be much more knowledgeable about a particular problem than we are. Realizing your limitations and delegating when beneficial is also a part of a security strategy. Long gone are the days when well meaning developers patched together their own authentication system with unencrypted emails in a database in order to be able to send out password reminders (in plain text emails). It is simply easier to use a library that does all this for you and, as an added bonus, does it well with encryption, email verification, password reset procedures etc. We do not mean to imply that a knowledgeable and skilled developer is no longer needed. Quite the opposite, but with Rails, using standard development methods and libraries, even a junior developer can avoid dangerous pitfalls.

Security Benefits of Open Source

The fact that Rails is Open Source, although it might sound counter intuitive, in our opinion adds security to the framework. Anyone, for good or bad, can study the internals of the framework and discuss alternative solutions, improvements or potential problems. Since the “good guys” tend to outnumber the bad and since, whenever a new security breach is found, the framework is constantly patched with security fixes we believe that the end product is more secure than a proprietary solution into which we have no insight. Just recently another huge security breach was exposed when Yahoo admitted to having more that one billion (yes – with a B) accounts exposed since 2013.

Although security breaches can happen to anyone, it seems unlikely that something that serious would go unnoticed for 3 years in a widely used open source framework. To us Open Source means security by transparency and faster fixes to any discovered issues.

Test Driven Development

Test Driven Development, or TDD for short, is another thing that is not specific to Rails but is made simpler since the framework prepares a structure for you in order to easily get started with your tests right away.

Basically, TDD is an approach to development where you start by defining tests that ensure your application does what it should and then proceed to implementing it. It provides a concrete way to prove that your application does exactly what it is supposed to do and brings many advantages to development, a couple of which concern security.

Whenever a malfunction occurs, such as a security problem of some sort, a new test is added highlighting the error and then a patch is applied. In the future, whenever modifications are made to our application we are guaranteed to have no regressions and that the problem will never occur again.

The presence of tests have another important impact on the security to our applications. They allow us to keep our framework and external libraries updated with the latest security fixes while maintaining the integrity of our application. As long as our tests pass after an update we can be sure that everything still works as before.

These benefits may seem small but anyone who has tried to keep an application of some complexity constantly updated with the latest patches knows that without TDD the experience is somewhat similar to playing Russian roulette (or so we can imagine).


Security needs to be an integral part of software development and not an afterthought that is hastily run through at the end of the development cycle. A solid framework is not a substitution for skilled and experienced developers but helps establish a good baseline of security. We have found that, for us, Rails is a good choice that helps us develop solid security conscious applications that are scalable and easy to maintain over time. If this sounds interesting to you, please don’t hesitate to contact us. We would like to work together with you and help you reach your goals!


Condividi su:

Daniel Jonasson

Senior Software Developer - Intesys
  • Rendere il business sostenibile: la strada è open source

  • Evolvere le Architetture IT: il futuro è sempre più open source

  • Open Hospital e Uni2grow Cameroun: l’open source diventa un’opportunità di crescita

  • Kubernetes: cos’è e come usarlo per orchestrare i microservizi aziendali

  • Open Hospital premiato al Liferay Global Partner Summit

Iscriviti alla Newsletter

Inserisci i tuoi dati e ti iscriveremo alla nostra Newsletter. Riceverai una mail ogni volta che uscirà un nostro nuovo articolo. Non ti preoccupare, non ti intaseremo la casella di posta e - se cambierai idea - potrai cancellarti in qualsiasi momento.
* campi richiesti
Privacy *