In an earlier post, we discussed what application security is and why it’s important. That was covering the basics. So, what next? Once you know the importance of application security, you should of course work on implementing it. But application security isn’t just one thing to do—it’s a collection of various security practices and approaches. So, in this post, we’ll discuss these practices and approaches.
Authentication is the means of confirming a user’s identity. In application security, the application can authenticate the user to allow the user to access the whole application or a component of the application. For example, internet banking applications require you to log in before accessing any feature or service. By contrast, an e-commerce application can let you browse its products without logging in, but you’ll have to log in to make a purchase.
There are different ways an application can authenticate a user. Passwords and OTPs are the most commonly used methods. There are three main factors of authentications:
- Knowledge: This refers to some information that you know (e.g., passwords, usernames, answers to security questions).
- Possession: This refers to an item or a device you have or possess (e.g., access cards, tokens).
- Something you are: This refers to a part of what you are (e.g., fingerprint, iris or retina scanning).
If you want high security, you have to use a combination of these factors for authentication.
Authorization is giving permission to a user on what that user can do. You can either authorize a person after they log in, or you can have the permissions stored earlier and then assign the permission when the user logs in.
I can’t complete this section without talking about the principle of least privileges. The principle of least privileges is a well-known and popularly used authorization practice. It states that an entity should be given only the permissions they need, at the time they need them. If there is a user who needs access to the file, then according to this principle, you should give the user permission to access only that file and only when they’re supposed to access it.
It goes without saying that data has to be kept private. A majority of applications these days deal with sensitive and confidential data. Whether it’s data in transit (data flowing between an application’s components) or data at rest (data stored in a data store), data encryption is important. Data encryption helps you prevent access to sensitive data from unauthorized entities.
You might find this section redundant from the previous section. Encryption provides data security, so why do we have a separate section? It’s because data security is more than just encryption. Encryption, of course, is a part of data security, but data security aims to achieve data confidentiality, integrity, and availability (aka the CIA triad).
Logs are a rich source of knowledge, and cybersecurity is incomplete without logs. When you build an application, you must implement proper logging mechanisms. Logs can help you understand and get information before, during, and after a security incident. If you use proper logging and take the required actions, you can prevent a lot of security incidents.
How do you know all your application security implementations are working? Through security testing. Security testing will help you know whether your implementations are working as expected or not. But along with that, it will also help you identify other security issues that you should work on going forward. There are different ways to security test applications. Let’s go through the two main categories of application security testing.
Static Application Security Testing (SAST)
SAST is the method of testing without actually running the application. You’ll look at the code to find security weaknesses. This is a good testing method to identify the use of dependencies with known vulnerabilities, unsafe handling of data, and so on. SAST is usually done in the earlier stages of application development.
Dynamic Application Security Testing (DAST)
Unlike SAST, DAST is the method where you’ll have to run the application to test it. DAST usually happens in the later stages of application development or after the application is complete and deployed. DAST is very useful in finding authentication and authorization weaknesses and functions that depend on the interaction of different components of the application.
Both SAST and DAST have their own pros and cons. But together, they are a complete package. So it’s always suggested to carry out both SAST and DAST rather than choosing one.
Application security is a critical and continuous process. You have to do most of the development and implement security measures manually. But there are also a lot of things you can automate. Especially when it comes to security testing, you’ll find many tools. One such tool is Snyk.
How Can Snyk Help?
Snyk will help you security test your application. It’s possible that you might have created vulnerabilities while developing your applications. You might have also used a dependency that’s vulnerable. And it’s not scalable for you to manually go through every bit of your application to find such issues. Snyk will scan your application’s code and find such issues and inform you about them. If that’s enough, Snyk can also fix vulnerabilities in your application. Snyk provides a wide range of repository support and reporting features. To get more insights about what Snyk can do and how, just check out this course on application security with Snyk.