For many years,<\/span>\u00a0security in application design and development has often been left up to either vigilant developers<\/strong> taking it upon themselves to produce quality code or to security reviews<\/strong> at the end of the development process (often with difficult and\/or costly refactorings as a result).<\/span><\/p>\n This approach could work well in theory, but in practice rarely does. It is unlikely that every\u00a0developer 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 <\/strong><\/span>security analyst will never tell you that an application is 100% secure<\/strong> – we cannot know what we do not know.<\/span><\/p>\n 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<\/a> framework. Any framework or any programming language can produce software with or without security flaws. <\/span>What really sets Rails apart though is that good design, intelligent defaults, best practices, and an emphasis on security \u201cout of the box\u201d make it easier to do the \u201cright thing\u201d<\/b>. In this article we will go over a few of the things that we think make Rails a good alternative for developing secure applications.<\/span><\/p>\n Developing <\/span>using Rails we get a lot of security features for free<\/b> using the generators provided and the defaults established by the framework itself<\/a>. 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.<\/span><\/p>\n In addition to the security features of the framework itself we have a whole host of options when it comes to<\/span> libraries adding security features<\/b> 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. <\/span>Realizing your limitations and delegating when beneficial is also a part of a security strategy.<\/b> 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.<\/span><\/p>\n 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 \u201cgood guys\u201d tend to outnumber the bad and since, whenever a new security breach is found, <\/span>the framework is constantly patched with security fixes<\/b> we believe that the end product is more secure than a proprietary solution into which we have no insight. Just recently\u00a0another huge security breach was exposed<\/a>\u00a0<\/span>when Yahoo admitted to having more that one <\/span>billion<\/span><\/i> (yes – with a B) accounts exposed since 2013.<\/span><\/p>\n 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 <\/span>Open Source means security by transparency and faster fixes to any discovered issues.<\/b><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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 <\/span>guaranteed to have no regressions and that the problem will never occur again<\/b>.<\/span><\/p>\nSecurity Needs to Be a Part of Development<\/span><\/h2>\n
Security Benefits of Open Source<\/span><\/h2>\n
Test Driven Development<\/span><\/h2>\n