Same Same, But Different:

Getting security testing

ready for the API-first era

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

July 2021

PAGE 3Key Takeaways

PAGES 4 – 7 The Importance of API Security Testing

PAGES 8 – 13 Common Approaches to Application Security Testing

Approach #1: Static Security TestingApproach #2: Dynamic Security TestingApproach #3: Penetration Testing

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

PAGE 16 About Imvision

Table of Contents

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

• 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 fit, but it’s very costly and lengthy.

• Since there’s no user interface, having knowledge of the app’s internal workings can help you efficiently 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.

Key Takeaways

3The dawn of a new approach: Business Logic 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 efficiencies like never before.

The Importance of API Security Testing

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

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.

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.

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

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

When looking at these figures 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 flaws. 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.

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.

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

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

In the past year, have you slowed down deployment to production (or considered to) due to API security 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 benefits, 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 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:

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

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

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

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

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

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.

And that number is likely to increase drastically with modern applications’ rapid adoption of and dependence on APIs.

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

Strength = API Security Weakness

APIs are designed to be flexible, reusable and expandable.

The type of bugs that lead to attack vectors are at the business logic or business process level and are therefore challenging to identify during staging.

APIs are designed to connect and integrate multiple vendors and sources.

Every API is unique and proprietary. As such, its software bugs and vulnerabilities are unique and “unknown.”

APIs let third parties customize their requests according to their needs

The types of requests the API will handle are unknown at the time of staging and it’s hard for the test team to anticipate all possibilities.

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.

Common Approaches to Application Security Testing

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

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

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 sufficient 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:

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

Static security testing takes a white-box approach, creating tests based on the known functionality of the application by reviewing the design, architecture, or code, including the many complex paths that data can take as it passes through the application.

Dynamic security testing takes a black-box approach, creating tests based on the expected performance of the application given a particular set of inputs, without regard to internal processing or knowledge of the underlying code.

Penetration testing involves creating a simulation of a genuine attack in an intensive search for vulnerabilities in the application.

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

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

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 configuration 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 specification (e.g., OpenAPI), this type of analysis commonly runs hundreds of security checks to test for common security issues, enabling developers to identify and fix those early on.

Table 2: Static security API testing pros and cons

STATIC SECURITY API TESTING PROS STATIC SECURITY API TESTING CONS

• Simpler to automate since all internal processes and paths are known

• Cannot identify problems with runtime and environment problems

• Can create highly granular tests adapted to structures within the code

• Usually doesn’t provide mitigation steps or remediation advice

• Easy to understand when testing should stop: when all branches and logical possibilities have been tested

• Business logic isn’t fully covered in test definitions

• Can be useful for debugging if bugs are related to the code itself

• Less helpful for APIs already in production (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

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

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.

Table 3: Dynamic security API testing pros and cons

DYNAMIC SECURITY API TESTING PROS DYNAMIC SECURITY API TESTING CONS

• Offers a more realistic simulation by mimicking real-world attack conditions

• Often involves manual processes, which do not scale well

• Simulates pen testing and provides a hacker’s-eye view

• Limited to known attack signatures

• Allows testing to be done by non-developers with no knowledge of code

• Doesn't adapt to fit unique business logic attacks

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

• Testing can be outsourced to third parties since the code remains hidden

• Difficult to design tests for complex data-handling 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

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

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.

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

DYNAMIC SECURITY TESTING STATIC SECURITY TESTING

Primary Strength Realistic; tests can be done by anyone with no insight into code

Thorough; tests can provide broad, deep coverage

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

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 efficiently 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.

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

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 find 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 flaws 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 field, 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 benefits, 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.

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 fit 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 sufficient. 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 find 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.

It’s Time for a Business Logic API Security Testing Approach

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

Once testing workflows 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 flaws. 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.

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

Once testing workflows 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:

• 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 flaws. But it is also time-consuming and expensive, whether done in-house or outsourced.

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.

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

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

Design Runtime

Schema AnalysisSchema Security Audit

Remediation Insights

Schema Creation

Security TestingBusiness Logic Testing

OWASP API 10 Testing

Schema Validation

Data-Driven DiscoveryFunctional Modelling

Endpoint Risk Scoring

Sensitive Data Exposure

Runtime ProtectionAnomaly Detection (NLP/AI)

Adaptive Prevention

Remediation Insights

Attack Analytics

17The dawn of a new approach: 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 workflow: detect, fix, test, deploy, repeat.

Introducing the World’s First Business Logic API Security Testing

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.

About Imvision - Full Lifecycle API Security