Security by Default: 5 Principles for Building More Secure Apps

Here are five principles that developers should keep in mind to create more secure apps

• By Madhan Kanagavel
• Nov 29, 2018

Last year, Accenture left four AWS S3 storage buckets without passwords, exposing sensitive data about the Accenture cloud platform and its clients. Likewise, MongoDB—a popular database platform—was discovered to be insecure by default, opening an attack vector to any apps using it. Both of these instances cite insecurities by trusted companies, with countless customers and connections. This type of carelessness leaves everyone open to attack. 

Today's apps are more interconnected and externally accessible than ever before. Before, with legacy software solutions, apps were isolated on a company's intranet and buried behind a firewall. Nowadays, apps exist in the cloud with integrations to countless other cloud-based services and data flows from one service to another, and from one user to another, creating a multitude of attack surfaces. 

Even the biggest and the brightest get security wrong sometimes, and this affects more than just themselves—that’s why building secure apps must become a best practice. Here are five principles that developers should keep in mind to create more secure apps:  

Principle One: Security Trumps Usability

Of course, as a developer, you want to create the next new shiny thing. And unfortunately, security is never really shiny. In fact, it's often not even visible at all. The most secure app may be one where security features aren’t ever noticed. While you may not receive the same pat on the back or crowd recognition for building a secure app as you would a center stage, hyped-app, it is far better than the recognition you'll receive if you're the cause of a security vulnerability that leaks personal data and plummets bottom lines. 

In recent years, software design best practices advocate for seamless user experiences and interfaces, sacrificing security at the altar of the usability god. Simply put, shipping software without proper security precautions is irresponsible. You wouldn't build a beautiful house without a lock on the front door, so why would you ship software without built-in security? 

Security needs to regain the throne in the realm of best practice. No matter the cost, usability should come after security, not first. Even if you are creating an app without real-world ramifications, an insecure app can function as an attack vectorfor a hacker to gain access to your larger system and cause real-world damage. 

Principle Two: Secure Configurations by Default

Relying on the end-user to make an app secure is, in essence, shipping insecure software. After building software for all kinds of end-users— consumers, enterprise IT admins, and even developers—I can say that very few people change the shipped defaults. One studyfound that just five percent of users actually changed any settings from default. It’s a similar uphill battle as getting users to change passwords. 

When installing a new piece of software, users typically take the path of least resistance. They do the minimum to get the app up and running and stop there. Many developers assume that they can ship software with wide open settings so users can configure the security later, but this simply never happens for the overwhelming majority of users. As soon as the app is up and running, security is never even considered.

This means that the default configuration the software ships with is critical and has to be as tight as possible. Additionally, you might require users to perform certain configurations before the software is considered up and running. Any security left to the self-determination of the end-user is likely to be a security gap, and nothing more.

Principle Three: Ensure Perimeter Security 

Modern software is complex. It is often cloud-based with connections to countless other solutions and users. As such, data comes from every direction, handled by different software layers. If security is handled by every single layer then security issues will explode. Under almost all conditions, the outermost layer - the software security perimeter—should verify and validate all input. Only if all security conditions are met should it let the next inner layer handle the input. 

Think about this outermost layer like a bouncer checking IDs for a club. If the bouncer allows someone inside after checking their ID, further checks are not needed. Similarly, at an airport, all checks are done at the gate. To create better perimeter security, the trick is to constantly ensure that the bouncer is doing his job correctly and adapting for whatever developments in fake IDs come down the pipe. 

Principle Four: Always Assume Lowest Security for Any Action + Condition 

Just because you're checking credentials at the door doesn't mean that once the user is granted access that they should have access to everything. Further checks are needed to get to deeper layers of functionality and information access. For example, just because you got past the airport gate, doesn't mean you can waltz into the airport control room. You still need higher privileges to get into it.

The same thing applies for software. The default level of access should have the least privilege. More importantly, if the checks don't pass, the default is the lowest possible security context and the action is disallowed. This principle of least privilegecreates software that is secure and robust by default. 

Principle Five: Always Create a Security Context

Successful security depends upon having a solid software framework in place inside the app from day one. Security added as an afterthought is always difficult to patch or retrofit when new attack vectors are identified. 

It should be easy to use software security constructs or it should be done for you by default. It should be harder to make something insecure than secure. A problem found after releasing the software where something is not available due to tight security is better than the opposite. Building complex security constructs would mean that it is less understood by developers and it is easier to use it incorrectly. 

Secure software is not impossible, just hard and like anything requires continuous effort and practice, but the rewards are worth it. By prioritizing security from the start, researching and evaluating technologies used to build an app, creating strong authentication and authorization steps, double checking secure communications and working to protect data with encryption, developers can eliminate potential vulnerabilities. 

While our new, interconnected cloud reality provides countless benefits, it also presents new types of risks that need to be accounted for during app development. Apps need to be purpose-built with security measures inherent to handle a variety of attacks and potential attack vectors. This is becoming even more true with time, as the IOT and machine intelligence become forces in daily life. Secure now, and you will not regret later.