Getting Security Testing Ready for the API-First

Same Same, But Different: Getting security testing ready for the API-ﬁrst era

How to prevent data breaches by proactively identifying API business logic vulnerabilities.

July 2021 Table of Contents

PAGE 3 Key Takeaways

PAGES 4 – 7 The Importance of API Security Testing

PAGES 8 – 13 Common Approaches to Application Security Testing Approach #1: Static Security Testing Approach #2: Dynamic Security Testing Approach #3: Penetration Testing

PAGES 14 – 15 It’s Time for a Business Logic API Security Testing Approach

PAGE 16 About Imvision

The dawn of a new approach: Business Logic API Security Testing 2 Key Takeaways

• APIs are growing in popularity but many organizations don’t even know the extent of their APIs and vulnerabilities.

• API vulnerabilities often take longer to remediate than traditional application vulnerabilities, so identifying them early is important.

• Hackers can easily probe available APIs for known and unknown weaknesses.

• API security testing can be very valuable, but often falls through the cracks.

• Common testing approaches, black-box and white-box testing, don’t really suit APIs well. Pentesting can be a good ﬁt, but it’s very costly and lengthy.

• Since there’s no user interface, having knowledge of the app’s internal workings can help you eﬃciently create functional tests for the business logic.

• It’s essential to place APIs front and center in your security controls, towards adopting a Full Lifecycle API Security model.

• Ideally, combining aspects of all these types of API security testing would create a grey-box solution that compensates for the weaknesses of each of these individual approaches.

• Such a business logic approach would intelligently examine results of other test types and can adapt to apply improved tests, either automatically or manually.

The dawn of a new approach: Business Logic API Security Testing 3 The Importance of API Security Testing

While APIs have been around since the early 2000s, today, they are everywhere.

APIs are now expected and demanded throughout the industry, and their use is still growing. And no wonder: APIs work like magic to interconnect disparate apps and devices, driving business synergies and eﬃciencies like never before.

Figure 1: Growth in API use driven by cloud, IoT, and other open standards (Source: Informatica.com)

In a 2021 survey, 73% of enterprises reported that they have more than 50 APIs, and this number is constantly growing.

The dawn of a new approach: Business Logic API Security Testing 4 From a business strategy perspective, APIs give you unprecedented power to share back-end data and functionality with customers, business partners, and other stakeholders. And their usefulness continues to expand, thanks to the estimated 80 billion IoT devices that will be in use by 2025.

Figure 2. Business goals driving API adoption (Source: “Gartner’s API Strategy Maturity Model”, 21 October 2019)

When looking at these ﬁgures on the growing importance of APIs, the most important takeaway is for businesses today: APIs are no longer solely a developer component hidden deep in the stack. They have become a key business enabler, if not the core of a business itself when it comes to API monetization.

But like any software component, APIs are bound to have security ﬂaws. And if they’re not tested rigorously from a security standpoint, they also offer a huge array of new attack surfaces and expose you to unprecedented risk.

It’s important to remember that APIs are more than just connectors; they shift your application’s functionality, often in unpredictable ways.

For instance, they move much of the processing logic from the backend to the frontend, which comes with a lot more vulnerabilities and factors beyond your control, such as HTTP requests becoming far more complicated since they involve more parameters when you’re dealing with APIs.

The dawn of a new approach: Business Logic API Security Testing 5 While API vulnerabilities become exploitable when deployed in production, they can still be discovered in a staging environment. The staging environment is essential because it lets your team perform a few essential pre-production steps: • Conduct QA and performance testing • Perform vulnerability testing and risk assessment • Handle integration testing to ensure all components (services, databases, and other dependencies) function as designed

Waiting until production to discover API vulnerabilities can result in expensive delays on the road to production.

In the past year, have you slowed down deployment to production (or considered to) due to API security concerns?

Figure 3: 60% of organizations have had to slow deployment to deal with API security testing concerns

This is the reason many companies are working to shift-left security and implement a DevSecOps approach. Shifting left has a number of proven beneﬁts, as it can: • Lower costs with earlier detection • Reduce the Mean Time to Remediate • Ensure deployment to production without delays

Many organizations are already convinced of the value of shifting-left security in general. By building testing into the software development lifecycle (SDLC), they ensure it is performed continuously throughout development to prevent bottlenecks near the end. Yet API security testing is often left out of the DevSecOps big picture.

This is unfortunate, given that API vulnerabilities often take longer to remediate than traditional application vulnerabilities. In a recent Imvision survey, 63% of respondents reported that it takes longer to remediate API vulnerabilities; even responses of “about the same time” are not the best thing since there are more APIs, thus more vulnerabilities.

The dawn of a new approach: Business Logic API Security Testing 6 And that number is likely to increase drastically with modern applications’ rapid adoption of and dependence on APIs.

Compared to traditional application vulnerabilities, with API vulnerabilities your average time to remediation is:

Figure 4: API vulnerabilities take much longer to remediate than traditional application vulnerabilities

The industry is beginning to wake up to the importance of API security, as many organizations are also aware of the increase in API-based attacks and fear they are at risk:

Do you feel your organization is at risk of suffering an API attack in the next 12–18 months?

Figure 5: Over 70% of organizations believe they are at risk for an API attack in the near future

Yet, the statistics reveal that many organizations struggle with understanding where to begin. While more than half of enterprise security leaders rate API security testing as one of their top-3 priorities to protect their APIs, just under half say they don’t yet have an API security testing solution fully integrated into their development pipeline.

This ebook will walk you through what you need to know about API security testing. We’ll explore the pros and cons of the most common approaches before looking at a new method that combines the best of both worlds to save you time and money while maturing toward a Full Lifecycle API Security approach.

The dawn of a new approach: Business Logic API Security Testing 7 Common Approaches to Application Security Testing

How can you tell if a security test is effective? In general, test effectiveness is measured using various code coverage metrics to determine the percentage of the code, the number of statements, or the number of functions that have been tested.

But these metrics don’t always include APIs or account for the complexities that they introduce into the testing setup.

Because of some of the unique weaknesses APIs may introduce, they demand a greater level of coverage than traditional apps, as even an obscure and unintended pathway may be exploited; this is opposed to a traditional UI-based approach, which only allows for certain prescreened input.

What this means, in short, is that many of the strengths of APIs - the reason the industry has rushed to adopt them - are also their greatest weaknesses from a security perspective, as shown in the following table.

Strength = API Security Weakness

APIs are designed to be ﬂexible, The type of bugs that lead to attack vectors are at the business logic reusable and expandable. or business process level and are therefore challenging to identify during staging.

APIs are designed to connect and Every API is unique and proprietary. As such, its software bugs and integrate multiple vendors and sources. vulnerabilities are unique and “unknown.”

APIs let third parties customize their The types of requests the API will handle are unknown at the time of requests according to their needs staging and it’s hard for the test team to anticipate all possibilities.

Table 1: Comparison table demonstrating how API strengths translate into inherent security weaknesses

The dawn of a new approach: Business Logic API Security Testing 8 Hackers are fully aware of the potential for APIs to open up vulnerabilities in your app. Beyond traditional web application vulnerabilities, there are many more ways in which an API may be vulnerable.

That’s why they have developed many different techniques to try to crack your app through its API. For instance, APIs are often attacked by legitimate, authenticated users that exploit the API using seemingly legitimate calls but with the intent to manipulate.

The range of potential vulnerabilities within APIs creates a great need for rigorous and thorough testing approaches.

Yet traditionally, one problem with API security testing has been that it’s usually handled separately from regular security testing. While unit and integration testing is taken care of during development, API testing is often handled as a separate task by QA. This sometimes means that API security testing can either fall through the cracks or be undertaken without suﬃcient awareness of the real risks involved.

To ensure a comprehensive approach, we should first consider the most common approaches to application security testing. Although these terms apply to all types of application development software that are well known, they function a little differently when it comes to testing your API security. Let’s look at their basic definitions first:

Static security testing takes a Dynamic security testing Penetration testing involves white-box approach, creating takes a black-box approach, creating a simulation of a tests based on the known creating tests based on the genuine attack in an intensive functionality of the application expected performance of the search for vulnerabilities in the by reviewing the design, application given a particular application. architecture, or code, including set of inputs, without regard to the many complex paths that internal processing or data can take as it passes knowledge of the underlying through the application. code.

Figure 6: Common Approaches to Application Security Testing (AST)

Let’s look now at some of the ways in which these testing approaches are different when it comes to API security testing.

The dawn of a new approach: Business Logic API Security Testing 9 Approach #1: Static Security Testing

Static application security testing (SAST), sometimes also known as white-box testing, is usually performed by the development team, as opposed to QA. This is a test of the program’s business logic, verifying that all branches function correctly and ensuring that conﬁguration and code are aligned with security best practices.

There is one common static security testing technique that is useful for API security testing: • Schema analysis. Using the API speciﬁcation (e.g., OpenAPI), this type of analysis commonly runs hundreds of security checks to test for common security issues, enabling developers to identify and ﬁx those early on.

STATIC SECURITY API TESTING PROS STATIC SECURITY API TESTING CONS

• Simpler to automate since all internal processes • Cannot identify problems with runtime and and paths are known environment problems

• Can create highly granular tests adapted to • Usually doesn’t provide mitigation steps or structures within the code remediation advice

• Easy to understand when testing should stop: when • Business logic isn’t fully covered in test all branches and logical possibilities have been deﬁnitions tested

• Can be useful for debugging if bugs are related to • Less helpful for APIs already in production the code itself (assuming they are known) • Automated tests require frequent updates as code changes • Outsourcing testing represents a greater security risk since it requires releasing the code

Table 2: Static security API testing pros and cons

The dawn of a new approach: Business Logic API Security Testing 10 Approach #2: Dynamic Security Testing

Dynamic application security testing (DAST), sometimes also known as black-box testing, is a strictly functional type of testing. Dynamic security tests don’t care howthe program is achieving results, as long as anticipated results are delivered under all circumstances. Dynamic security testing is usually performed by QA or security, as opposed to the development team.

Here’s a brief overview of a few common dynamic security testing techniques that can be useful for API security testing: • Validation and functional testing. Verifies that the API functions as designed, returning expected results while blocking unexpected and unwanted code that might indicate an attempted injection attack. • Load testing. Verifies that the API functions correctly even under load conditions, or throttles if necessary; also useful to benchmark requests served per minute. • Fuzz testing. Verifies that the API performs predictably when served with random and unexpected data.

DYNAMIC SECURITY API TESTING PROS DYNAMIC SECURITY API TESTING CONS

• Offers a more realistic simulation by • Often involves manual processes, which do not scale mimicking real-world attack conditions well

• Simulates pen testing and provides a • Limited to known attack signatures hacker’s-eye view

• Allows testing to be done by • Doesn't adapt to ﬁt unique business logic attacks non-developers with no knowledge of code

• Generally faster and simpler to implement • If performed in a staging environment, may not reﬂect real-world parameters/scale

• Testing can be outsourced to third parties • Diﬃcult to design tests for complex data-handling since the code remains hidden algorithms without visibility into their logic

• Complexity increases with microservices and distributed applications

• Often done too late in the DevOps process, creating blockages that prevent release

Table 3: Dynamic security API testing pros and cons

The dawn of a new approach: Business Logic API Security Testing 11 Which Approach Is Better for APIs, Static or Dynamic?

Here’s a basic summary of the strengths and weaknesses of each of the approaches we’ve looked at so far.

DYNAMIC SECURITY TESTING STATIC SECURITY TESTING

Primary Strength Realistic; tests can be done by anyone Thorough; tests can provide broad, with no insight into code deep coverage

Primary Weakness Manually configured; difficult to scale Inflexible; can’t help in production

Table 4: Primary strengths & weaknesses of static and dynamic security testing

It’s quite common for developers to argue over which type of testing is most appropriate when it comes to APIs. This leads to two prominent myths about API security testing:

• API Security Testing Myth #1: Static testing is the only valid approach. That’s because there’s no real “user interface” for APIs, and therefore, according to this view, you must know what’s going on inside the business logic.

• API Security Testing Myth #2: Only dynamic testing is necessary. According to this view, since unit tests use a static model and have already been taken care of at an earlier stage in the development pipeline, dynamic testing is all that’s needed before production.

But the truth is that neither of these views is completely correct. In fact, both approaches are necessary so you can create broad coverage and handle a range of potential scenarios.

When it comes to API security testing, a ‘grey-box’ testing approach can provide a helpful alternative. Since there’s no user interface, having knowledge of the app’s internal workings (e.g., parameters, return types) can help you eﬃciently create functional tests.

Such grey-box testing for API security would involve creating a test engine that is adaptive and can learn as it goes, developing a deeper awareness of a program’s behavior in order to intelligently reverse-engineer its hidden inner workings.

The dawn of a new approach: Business Logic API Security Testing 12 Approach #3: Penetration Testing

Penetration testing, or pentesting, is an approach that analyzes application performance and simulates attacks given permitted or forbidden security parameters, credentials, etc.

Pentests can be done through formal in-house testing programs, but many companies at this stage may also bring specialized personnel on board to ﬁnd as many security vulnerabilities as possible in a given span of time. Another option is crowdsourcing the organization’s vulnerability program with the cooperation of ethical hackers.

Ethical hackers are researchers who study security weaknesses and use this knowledge to help companies strengthen their security programs. Like hackers, they approach the system as a black box, with little or no inside knowledge of how it functions. Drawing on knowledge of common vulnerabilities and weaknesses, they methodically attack the system until its ﬂaws are revealed.

When it comes to your APIs, they intercept and observe how these function, just as a hacker would, laying bare their vulnerabilities.

The difference is that once they discover vulnerabilities, they provide you with this information, which then helps enhance their reputation and bring in legitimate business, since many ethical hackers also work in the security ﬁeld, for instance, as penetration testers.

Rather than hiring ethical hackers full-time, companies can offer Bug Bounty programs in order to:

• Incentivize the reporting of vulnerabilities to the company rather than selling them to malicious actors

• Create an “aura” of the vendor’s deep commitment to security

Also called vulnerability rewards programs, Bug Bounty incentives vary, and the programs are subject to change quite frequently. Bug Bounty programs can have great beneﬁts, yielding deep insights into software vulnerabilities limited only by the ingenuity of the researchers participating.

However, they are also costly for organizations, both in time and money, which ultimately limits their potential scope and frequency.

The dawn of a new approach: Business Logic API Security Testing 13 It’s Time for a Business Logic API Security Testing Approach

As we have seen, while most organizations intend to implement API security testing, few have a plan to accomplish this, let alone a comprehensive plan that will cover some of the unique vulnerabilities APIs create. Given these discouraging statistics, it’s clear that in most organizations, this crucial component is falling through the cracks. Why?

• API security testing doesn’t ﬁt a single model. Neither the static, dynamic, or penetration model applies perfectly; plus, different departments are responsible for each type of testing. Often, QA and development departments may both assume “someone else” is responsible for API security testing.

• API security testing is invisible. Many organizations still believe UI-based testing is suﬃcient. They may test web/app/mobile separately, but don’t test the API itself. Also,with legacy APIs, you may not even have insight into all the APIs already in place or the relevant documentation.

• API security testing is costly. First, it’s manually intensive and doesn't scale when you have dozens and hundreds of APIs. Second, testing the business logic is complicated and requires greater expertise than other types of testing.

In today’s development world, in which APIs increasingly become mission-critical, it’s essential to place APIs front and center in your security controls, towards adopting a Full Lifecycle API Security model.

To do this, you must ﬁnd ways to simplify and streamline your organization’s API security testing, integrating and enforcing API security testing standards within the development cycle. This way, along with runtime monitoring, the security team can gain visibility into all known vulnerabilities in one place. As a bonus, taking steps to shift-left API security testing will cut costs and accelerate time to remediation.

The dawn of a new approach: Business Logic API Security Testing 14 Once testing workﬂows are properly automated, you’ll also gain built-in support for an integrated regimen of retesting: a cycle of test, remediate, retest, and deploy, keeping your pipeline working optimally and helping avoid bottlenecks altogether.

As seen above, the answer does not lie in a single model—there is no either/or when it comes to API security testing. Each approach has advantages and disadvantages:

• Static API security testing: Does the code follow best practices? Does it open up known potential vulnerabilities? This testing approach is great for covering the basic logic of the app but cannot detect unknown factors.

• Dynamic API security testing: Does the API do what it’s supposed to do? If not, this leaves the API open to exploitation. This testing approach is valuable for closing many obvious security gaps, but isn’t a helpful approach for business logic unless the tool can be highly customized.

• Penetration testing: How many vulnerabilities can expert testers discover in the app and API over a given test period? This testing approach can prioritize severe and easily exploited vulnerabilities and yield a rich list of API security ﬂaws. But it is also time-consuming and expensive, whether done in-house or outsourced to red teams or ethical hackers.

Ideally, combining aspects of all these types of API security testing would create a grey-box solution that compensates for the weaknesses of each of these individual approaches. Such a business logic approach would intelligently examine results of other test types and can adapt to apply improved tests, either automatically or manually.

A business logic approach to API security testing can elevate the maturity of your Full Lifecycle API Security program, and improve your security posture.

However, this modern approach demands a tool that can learn as it goes, improving its performance over time by ingesting runtime data to gain insights into the application’s structure and logic.

The dawn of a new approach: Business Logic API Security Testing 15 Once testing workﬂows are properly automated, you’ll also gain built-in support for an integrated regimen of retesting: a cycle of test, remediate, retest, and deploy, keeping your pipeline working optimally and helping avoid bottlenecks altogether.

As seen above, the answer does not lie in a single model, and each approach has advantages and disadvantages:

Ideally, combining aspects of these API security testing types would create a grey-box solution that compensates for weaknesses of each individual approach.

A business logic approach to API security testing can elevate the maturity of your Full Lifecycle API Security program, and improve your security posture.

However, this modern approach demands a tool that can learn as it goes, improving its performance over time by ingesting runtime data to gain insights into the application’s structure and logic.

Schema Analysis Data-Driven Discovery Schema Security Audit Functional Modelling Remediation Insights Endpoint Risk Scoring Schema Creation Sensitive Data Exposure Design Runtime Security Testing Runtime Protection Business Logic Testing Anomaly Detection (NLP/AI) OWASP API 10 Testing Adaptive Prevention Schema Validation Remediation Insights Attack Analytics

Figure 7: Business Logic Testing as part of the Full Lifecycle API Security Strategy

The dawn of a new approach: Business Logic API Security Testing 16 Introducing the World’s First Business Logic API Security Testing

Imvision’s Business Logic API Security Testing (BLAST) is a unique security testing capability, simulating business logic attacks based on production data. With BLAST, you can automatically test far beyond the schema, proactively protecting from Zero-day attacks to prevent data breaches and sensitive data exposure.

BLAST gives you the best of the white- and black-box approaches: automation with enhanced visibility and control. BLAST helps align teams around what matters, while keeping up with fast-paced API changes. BLAST supports your remediation efforts by enabling a rapid re-testing workﬂow: detect, ﬁx, test, deploy, repeat.

About Imvision - Full Lifecycle API Security

At Imvision, we help enterprises open up without being vulnerable.

The Imvision Full Lifecycle API Security platform helps security teams, discover, test, detect, and prevent API breaches.

Automatically provide every API the protection it deserves: wherever it is, at any scale, across its lifecycle.

For more information, visit our website, contact via email, or follow on LinkedIn.

The dawn of a new approach: Business Logic API Security Testing 17