Born Secure: Vulnerability Risk Factors in API Development
- 21 September, 2021
- Reading Time: 6 mins
Are your applications born secure? Is your API vulnerable? Do you have a strong, overlapping set of defenses? These questions are important for software developers and organizations who believe that security is something that an application should be born with.
Security can be an integral part of the agile methodology, and applications can be made secure from day one of development.
The developers who work dedicatedly to make their applications robust, scalable, performance-intensive, and clean often compromise on this important factor. They focus on security only when the application is complete and ready to be used by the end-user.
OWASP API Security Top 10
Initially, the OWASP Top 10 was a list of the most important vulnerabilities unique to web applications. It was first released in 2003 and is usually renewed every two or three years.
It focuses on vulnerabilities inherent in web applications such as cross-site scripting. The API Top 10 was first released at the end of 2019.
Application programming interfaces (APIs) expose data to web applications in different ways. Web applications expose the user interface, but the API exposes only the program’s interface, as the name implies. Through this interface, programmers can access data and features within their software.
This software can take many forms. For example, a mobile application could use the API to perform tasks and store data. It can also be a web application that uses an API to serve data to an interface. The original OWASP Top 10 are still useful for web applications, but they are becoming much more popular as you can see web applications that use native APIs to drive them.
Education Technology is another large area of use for APIs. When integrating with other applications, the respective edtech applications and LMS’s expose the API for data retrieval and posting. Since the functionality provided by the API has a lot in common with web applications, it is not surprising that there is overlap between the vulnerabilities seen in the OWASP Top 10 and the OWASP API Top 10.
Quoting directly from OWASP – ” The goal of OWASP API Top 10 is to educate those involved in API development and maintenance.”
Rarely a day goes by without a report in the press about an attack against even the largest of companies. Imagine a student’s personal data or health data being compromised on an insecure API. Software development teams need to be educated and made aware that they can build born secure APIs.
The top 10 vulnerabilities checklist can prepare them to protect themselves from the security issues they are most likely to face. In 2014, 47% of traffic was API-based. This is a significant amount of traffic, showing that about half of the traffic at the time was actually web pages. By 2018, that number had risen to 83%. This is a significant increase and demonstrates the importance of Internet APIs.
One can also see why API TOP 10 appeared in 2019. With so many APIs, it makes great sense to provide dedicated secure resources. Consider the number of websites currently supported by the API. Mobile phones are a good example. Most of the apps out there use the API. Some of these apps use the API when the app itself is not used.
Before exploring what OWASP API TOP 10 are, it is important to explore the main risk factors that OWASP takes into account for each vulnerability.
Vulnerability Risk Factors
Below are the key risk factors that OWASP takes into account for each vulnerability. We have attack vectors, vulnerabilities, and impacts.
Source : https://owasp.org/www-project-top-ten/assets/images/Risks-2017.png
Let’s get into the details.
1) The first thing is exploitability. How easy is it to exploit the vulnerability once it has been found? The easier this is to do, the greater the risk to the API. Various factors impact exploitability. For example, some vulnerabilities have tools available to help exploit the vulnerability. Some tools can help an attacker to a small extent, while others can automate the entire exploitation process. In addition, user interaction needs can affect the operability of some issues.
Some vulnerabilities are waiting to be exploited, while others require user action. Sometimes, exploitation is not easy to repeat. It may require circumstances beyond the control of the attacker to work. Privileges may also be required. For example, an attacker may need to log in to the API to exploit this vulnerability.
The following picture shows OWASP’s Risk Rating Methodology,
2) Prevalence – It shows us the commonness of vulnerabilities. Prevalence can vary greatly due to vulnerability. The things that affect popularity commonly come from a lack of awareness or knowledge of vulnerabilities, which is why API Top 10 is so important.
Complicated things often have a big impact on prevalence, and anything complicated has a much greater chance of being implemented incorrectly. Some prevalence comes from immature tools. Maybe they don’t have a secure default setting, or they just haven’t been around long enough for people to notice the issues they have. Lack of time is also a problem. If the safety function takes time to implement, it is unlikely to be completed.
3) Detectability – It tells us how easy it is to find vulnerabilities. The more skilled an attacker is, the more likely they are to discover vulnerabilities. Similarly, some vulnerabilities have tooling that makes them easier to find.
Vulnerabilities that are difficult to detect may still have tools, but they may also produce false positives, which means they require verification, usually manual verification. This means that more minor detectable vulnerabilities may require brainpower to find them.
4) Impact – In the end, we’ve got the impact. The technical impact is generally divided into confidentiality, integrity, and availability, also known as the CIA triad.
Confidentiality and integrity generally refer to data. Any impact on confidentiality means that information that isn’t intended to be shared has been exposed. An example is that a user can access data that belongs to another user.
Integrity means that the data is modified when it shouldn’t have been allowed. Again, this may be a user who can change data belonging to other users. Finally, an availability hit means that something is not available. This may be a complete API, a database, or something smaller, as part of the API, or it may deny access to a single user.
Are you born secure?
EdTech developers develop useful applications for the classroom. They keep looking for programmable web education technology categories to find the best Application Programming Interfaces (APIs) to use for their “EdTech” apps.
Today’s EdTech supports innovation in teaching and nourishes learning. However, the same technology makes it vulnerable to cyber-attacks. It brings risks to student privacy and safety and increases the risks in terms of data leakage and ransomware attacks.
Fortunately, we can take some steps to manage EdTech security risks and OWASP top 10 plays a vital role in getting there.
So, Is the confidentiality or integrity of your data affected? Is the availability of your service affected?
A vast and growing number of APIs can be potential targets for attackers, and the knowledge, skills, and tools they have only improved over time.
Securing your API against vulnerabilities is vital to its success.
References
https://owasp.org/www-project-top-ten/2017/Application_Security_Risks.html
Akhil Mittal
Akhil is a C# Corner MVP, Code Project MVP, ex- Microsoft MVP, a blogger, author who loves to write/read technical articles. He brings an experience of more than 12 years in developing, designing, architecting enterprises level applications primarily in Microsoft Technologies
Explore the latest insights
