Wake up! Identify API Vulnerabilities Proactively, From Production Back to Code

After more than 20 years in the making, now it’s official: APIs
are everywhere. In a 2021 survey, 73% of enterprises reported that they
already publish more than 50 APIs^[1], and this number is
constantly growing.

APIs have crucial roles to play in virtually every industry
today, and their importance is increasing steadily, as they move to
the forefront of business strategies. This comes as no surprise:
APIs seamlessly connect disparate apps and devices, bringing
business synergies and efficiencies never witnessed before.

However, APIs have vulnerabilities just like any other component
of the software. Adding to that, if they aren’t rigorously tested
from a security standpoint, they can also introduce a whole new
array of attack surfaces and expose you to unprecedented risks. If
you wait until production to discover API vulnerabilities, you can
incur substantial delays.

APIs are attractive to attackers, not just businesses

Keep in mind that APIs do more than simply connect your
applications; they change the functionality in unpredictable ways.
Many of the unique weaknesses that APIs may introduce are well
known to hackers, who have developed different methods to attack
your APIs in order to access the underlying data and
functionality.

According to the OWASP API Top 10^[2], it is not uncommon for
legitimate, authenticated users to exploit the API by utilizing
calls that appear legitimate but are actually intended to
manipulate the API. These kinds of attacks, aiming to
manipulate the business logic and exploit design flaws,
are attractive to attackers.

You see, every API is unique and proprietary. As such, its
software bugs and vulnerabilities are unique and “unknown” as well.
The type of bugs that lead to attacks at the business logic or
business process level is particularly challenging to identify as a
defender.

Are you giving API security testing enough attention?

Shift-left security is already widely accepted in many
organizations, allowing for continuous testing throughout
development. API security testing, however, often falls through the
cracks or is performed without a sufficient understanding of the
risks involved. Why is that? Well, there is more than one
reason:

1. Existing application security testing tools are generic and aim
   at traditional web app vulnerabilities, and can’t effectively
   handle the business logic intricacies of an API.
2. Because APIs don’t have a UI, it is common for companies to
   test web, app, and mobile separately – but not the API itself.
3. Testing APIs can be manually intensive and is not scalable when
   you have hundreds of them.
4. Relevant experience and expertise may be in short supply, as
   API testing is more complicated than other types of testing
5. With legacy APIs, you might not know about the APIs already
   implemented or the documentation.

So, while shift-left security is already valued by many
organizations in general, API security testing is too often left
out of the DevSecOps big picture.

This is unfortunate, since API vulnerabilities require longer to
remediate than traditional application vulnerabilities – in a
recent survey, 63% of respondents reported that it takes longer to
remediate API vulnerabilities. This number is also likely to rise
given applications’ rapid adoption of and dependence on APIs.

While most security leaders are aware of the importance of API
security testing, just under half say they don’t yet have an
API security testing solution^[3]
fully integrated into their development pipeline.

Learn more on how to prevent attacks by
proactively identifying vulnerabilities, from production back to
code.^[4]

Why do common security testing approaches fail to cover
APIs?

As a first step towards a comprehensive approach, it is
important to examine the most common attitudes towards application
security testing today: static security testing and dynamic
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, disregarding internal
processing or knowledge of the underlying code.

When it comes to APIs, developers and security teams frequently
argue over which of the two methods is most appropriate, with the
leading reasoning in favor of each being:

• Static testing is the only method that makes sense: since there
  is no user interface for APIs, you have to know what’s going on
  inside the business logic.
• Dynamic testing is all that is needed, since unit tests use
  static models and have already been completed at an earlier stage
  of the pipeline.

Sorry to ruin the party, but both of these points are only
partially true. As a matter of fact, both approaches are necessary
to ensure broad coverage and handle a variety of possible
scenarios. Especially with the current rise of API-based attacks,
you cannot take any chances when it comes to scalability, depth,
and frequency.

‘Grey-box’ API security testing may offer an interesting
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 that focus on the
business logic.

Ideally, combining aspects of API security testing would get you
closer to creating 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.

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

There’s growing industry awareness surrounding the need to
secure APIs across their lifecycle, placing APIs front and center
in your security controls.

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.

Moreover, once your testing workflows are automated, you’ll also
have built-in support for retesting: a cycle of test, remediate,
retest, and deploy, keeping your pipeline running smoothly and
avoiding bottlenecks altogether.

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

This would involve creating an adaptive test engine that can
learn as it goes, developing a deeper knowledge of the API’s
behavior in order to reverse-engineer its hidden inner workings
intelligently. Using runtime data and business logic information,
you can enjoy the best of both worlds – the black and white box
approach towards enhanced visibility and control with
automation.

Learn more on how to prevent attacks by
proactively identifying vulnerabilities, from production back to
code.^[5]

To wrap up

In addition to their increasing popularity, APIs also create
greater vulnerability for web applications. A large number of
organizations do not even know what the extent of their APIs and
vulnerabilities are. Known and unknown weaknesses can easily be
probed by hackers via available APIs.

However, API security testing is often overlooked and handled
the same as web applications. Most testing approaches, such as
black-box and white-box testing, are not conducive to API
testing.

A combination of natural language processing and artificial
intelligence (AI) offers a viable “grey box” option that automates,
scales, and simplifies the complex process of API security
testing.