How to avoid security issues in your app - our best practices

Information architecture and app security

A web application’s UX/UI is just the visual part of the user experience. Behind it there are many layers of data and processes working in the background. None of these “under the hood” mechanics are visible to users until there’s a glitch, or worse, a security breach. What can product stakeholders do to minimize such risks? Let’s look into app security best practices.

The basic thing your development team can do when starting a new product is to create (even the simplest) scheme for how your product uses data. What do we mean by “data”? In short: information. Information such as each client’s first and last name, home address, social security number, annual income, etc. Some of that information will be sensitive, and some of it - if leaked - may even put someone in danger.

Application security must be always viewed as a whole ecosystem. One small web or mobile app vulnerability can lead to a catastrophic situation. We need to consider security on different levels too. For example, if we split an application into microservices we need to ensure that each microservice is secure, and the communication between them is carried out securely too.

What tools could your team use? At Boldare, we suggest using Docker Networks or protecting microservices with a load balancer. The HTTPS standard used between the end user and the application is something we would strongly recommend. It’s really not rocket science, and most importantly, it’s not time consuming, so it will not overly affect the budget.

User passwords

Most apps handle users and their accounts, and many user actions must be authenticated. Some of the highest application security risks relate to login passwords and data storage methods. In most modern web applications, there’s the possibility of logging in via Google, Twitter, Facebook or another ubiquitous service. When it comes to choosing a verification model in your application we strongly recommend this method. The above-mentioned companies are trustworthy and their security policies and standards are top-notch. Not to mention their budgets, which are unreachable for most businesses.

Of course you need to keep in mind various disadvantages of this approach. For example some services, like Google, are not available in certain countries. Also, not everyone uses Google or Facebook so restricting your login procedure to this route will also restrict your users.

An especially insecure login option is to store user passwords in plain text, i.e. just copying the text entered in the “password” field straight to your database. Ironically, this approach has multiple advantages: if someone forgets the password, you can just email it to them. Password checking is much easier too. But this solution is very naive. If someone gets into your database - through a security breach, or because they’re an insider with access (such as an employee) - they can read the stored data.

This solution is even more dangerous when you consider that most users reuse the same password for their email accounts and other applications. A single breach can result in multiple breaches. So, let’s focus on a solution that allows us to store such information properly: cryptography.

Most modern applications are using password hash salting algorithms. There are many hash algorithms nowadays, the most common and secure options right now are bcrypt and argon2i. With properly used encryption, even after a successful attack and data leak, the attacker won’t be able to read the stored password. However, it’s important to always use the newest solutions and standards, because the older a method is, the less secure it becomes. If, for various reasons, you cannot use services like Google, Facebook or Twitter - that’s the best approach.

Even basic issues, such as user authentication is a relatively complex concept and requires a degree of knowledge and experience to do it safely. According to the OWASP Top 10, the second most common security risk is “cryptographic failure” (source), meaning that password or credit card number leaks are one the most common security issues on the web.

Third party vendors and dependencies

Another very popular avenue of attack is the applications vendor. This application security risk occurs when your digital product relies on external libraries to implement certain functionalities, instead of libraries developed from scratch, in-house. Such a situation is commonly described as “dependency”. Dependency takes place regardless of the external library size – it can be as small as a single document, or as large as a set of packages.

For instance, let’s imagine that you’ve written an outbound sales platform and want to add a functionality that lets you track email open rates. Instead of your in-house team coding this module (it’s expensive and time consuming), you use a third party library. From that moment onward, your tool’s message open functionality depends on the external library’s developers.

From a development point of view, your team has developed and delivered the functionality much faster because they used code written by a third party. Now, you need to ask yourself:

• Who made the solution I am about to use?
• Can I trust the author?
• How secure is the solution?
• What makes one package more trustworthy than another?

Let’s focus on a few factors that influence the overall trustworthiness of a “dependency”.

Author: Who contributed to this package? Is it someone well known and involved in a particular language community?

Support: How often is the package updated? How does the author react to issues created by other users? Are there any open issues? How long does it take to fix a bug?

Publicity: How popular is the package? Is it popular in the community?

Even if the package is managed by a respected person, is updated on a regular basis, and feedback is acted on quickly, it doesn’t mean that the package is 100% safe, or that it will stay safe forever. We recommend investigating the costs of implementing any feature by an in-house team and compare that to using a third party package. Also, make sure that your development team has a safety policy regarding dependencies and their security.

One of the tools your team can use to check dependencies is DependBot - it’s a free plugin that you can enable in GitHub for every repository. It scans the codebase and the lock file and focuses on the definition of all packages and their dependencies. When vulnerabilities are found, it sends an email notification and, if the fix is already available, edits files on a new branch, creating merge requests automatically.

To check a package’s health status we can also use commands shipped with our programming tools, such as the npm audit command. Some programming languages like PHP have a mechanism called self-package-checker: you need to import a package and, when imported, the mechanism will check all other packages for known security issues. This useful feature can be installed and adapted to a product in just a few minutes.

The weakest link in app security

We can discuss numerous technological ways of securing digital products, but we will never find a perfect solution. The reason is simple: the human factor. While developers can learn from their mistakes, there’s no way to predict the behavior of every single potential user. There will always be the possibility that someone will be able to bypass even the smartest safeguard, either now or in the future.

We’re working in a VUCA environment, in a world where technology evolves faster than ever before, and the accepted security methods of a few years (or even months!) ago may not be secure anymore. In the process of product design and development, all developers should keep it in mind, not just those who specialize in app security issues.