State of API Security

Q1 2023

1
Executive Summary
The State of API Security in Q1 2023

The State of API Security Report from Salt Labs is the industry’s first on API security risks, Respondents identified vulnerabilities as one of the top security issues they had experienced
challenges, and strategies. The fifth edition of this pioneering research offers security, DevOps, with production APIs. While 41% stated they had experienced such API vulnerabilities, Salt Labs'
and risk management teams a deeper perspective into the dozens of factors that impact API research suggests that this number is severely underestimated. In 90% of investigations, Salt
security. It also provides insights on building strategies to reduce the growing API attack surface. Labs identifies API security vulnerabilities, 50% of which should be considered critical.

As with previous editions, this report incorporates survey results and empirical data from the Despite all of the API challenges, API security practices are still maturing. Survey respondents
Salt SaaS platform hosting our customers' API metadata. This year, we have also included some are largely relying on traditional approaches to API security such as WAFs, API gateways, and
thought-provoking API vulnerability research from Salt Labs that illustrates how some of the API analyzing log files, but only 23% find these methods very effective. It’s therefore not surprising
security concerns highlighted by survey respondents can manifest in real-world scenarios. that only 12% of respondents believe their API security programs are advanced, while 30% say
they are non-existent or in planning.
The most eye-opening finding from the Q1 2023 report was that 94% of respondents have
experienced security problems in production APIs over the past year, with 17% having Documentation continues to be a challenge for organizations as only 19% of respondents
experienced an API-related breach. Another important finding from Salt customer data is that were very confident that they have a complete API inventory. One challenge in this area is the
attackers have upped their pace with a 400% increase in unique attackers over the same frequency of API updates – 37% of organizations update their APIs at least weekly. Similarly,
time period six months ago. There is little doubt that API security must become a key focus for only 18% are very confident they understand which APIs expose PII data.
security professionals in 2023.
APIs are at the core of every modern application, and attackers continue their efforts at
Attackers are also finding new and unexpected ways to target their efforts. In the past, unprecedented rates. Survey responses and Salt customer data overwhelmingly demonstrate
organizations believed that proper authentication to interact with an API was enough deterrent that the time is now for organizations to get serious about securing their APIs.
to send attackers elsewhere. Salt Labs data shows that 78% of attacks come from seemingly
legitimate users, but are actually attackers who have maliciously achieved the proper Research Methodology
authentication. Additionally, attackers have been targeting internal APIs, with 8% of attacks To understand the state of API security today, Salt Labs – the API threat research arm of Salt
perpetrated against these supposedly well protected assets. Security – initiated and compiled this API security industry report. Our in-depth research
combines survey responses and empirical data sfrom Salt Security customers. The findings
Survey respondents also indicate that API security has become a major business issue for their reflect the input of nearly 400 security, DevOps, and app development professionals across
organizations. 59% have experienced application rollout delays due to security issues identified companies big and small, in a variety of industries across the globe (page 19). Salt Labs also pulls
in APIs. Application rollout issues inevitably cause business disruption, which raises alarms at aggregated and anonymized data from the SaaS component of the Salt Security API Protection
all levels. And, with API security breaches becoming so newsworthy, it’s no surprise that 48% of Platform – this empirical data gives more context to the survey response findings.
survey respondents say that API security is now a C-level discussion.

2
Table of Contents

Executive Summary 2
API attacks are on the rise 4
API security has emerged as a significant business issue, not just a security problem 5
Respondents are experiencing significant API security challenges 6
The OWASP API Security Top 10 – a critical starting point 7
"Zombie" APIs top the list of API security concerns 8
Most API security strategies remain immature 9
What are security teams looking for in an API security solution? 10
Traditional approaches to API security are falling short 11
APIs are changing constantly and documentation is failing to keep up 12
Security teams have a difficult time understanding which APIs expose PII 13
APIs continue on their explosive growth trajectory 14
Salt Labs research: Vulnerabilities discovered in the wild 15
Recommendations and conclusions: Implications for API security 18
About the data 19
Additional resources 20
About Salt Security 21

3
API attacks are on the rise
Attackers are more relentless than ever and are starting to target internal and authenticated APIs

Bad actors are tenacious and are continuing to find new and unexpected ways to attack. In the facing the outside world. However, Salt Labs data shows that 8% of attack attempts are perpetrated
past, organizations believed that proper authentication to interact with an API was enough of against internal-facing APIs, which are typically left entirely unprotected.
a deterrent to send attackers elsewhere. Salt Labs data shows that 78% of attacks come from
seemingly legitimate users, but are actually attackers who have maliciously achieved the proper Also interesting is the significant rise in attackers targeting our customer base. The end of last year
authentication. saw a major spike, with 4,845 attackers operating in December alone – a 400% increase from just a
few months prior. This report marks the first time we have shared this level of information, but given
Internal-facing applications have also historically been deemed “safe” and, as such, security teams this increase, we felt it necessary to advise the industry that attackers targeting APIs are incredibly
weren’t particularly concerned about requiring robust security because these applications weren’t active.

Salt customer data: Unique attackers Salt customer data: Attack attempts from authenticated Salt customer data: Attack attempts against
targeting customer APIs during 2022 vs. unauthenticated attackers internal and external facing API endpoints

4842
8%
Unauthenticated Internal APIs
attackers

22%

497
123 78% 92%
Authenticated External APIs
attackers
Jan 2022 June 2022 Dec 2022

4
API security has emerged as a significant business issue, not just a security problem
59% have delayed an application rollout over API security issues, and the C Suite is getting involved in the discussion

Every application owner’s worst nightmare is a delayed rollout or the rollback of a new application. Application rollout delays cause business disruption, which raises alarms at all levels. Add the fact
Survey respondents told us that API security concerns have led to this very result far too that API security breaches are making headlines so often and it’s no surprise that this topic is now
frequently. An unfortunate 59% have experienced application rollout delays resulting from being discussed in executive and board meetings. In fact, 48% of survey respondents say that API
security issues identified in APIs. security has become a C-level discussion over the past year.

This high percentage illustrates the sad fact that no amount of testing and security-minded code It is interesting to note that the C Suite is paying closer attention in highly regulated industries
development can address today’s API security challenges. Developers cannot anticipate every such as technology (59%), financial services (56%), and energy/utilities (55%). When factoring in
possible business logic gap in their APIs, and pre-prod API testing tools similarly cannot identify company size, executives are most involved in the API security discussion at companies in the 5001-
these gaps. 10,000 employee range (71%) and least involved in companies of 10,000 employees or more (34%).

Have you ever slowed the rollout of a new application into production Has the security of your APIs become a C-level discussion
because of API security concerns? at your organization?

I don't know I don't know

12% 11%

59% 48%
29% Yes 41% Yes
No No

5
Respondents are experiencing significant API security challenges
94% of respondents have experienced security problems in production APIs, with 17% having experienced a breach

API security problems are a real concern for survey respondents. 94% had some security issue Given the prevalence of security events, it’s no surprise that respondents lack confidence in the
with their production APIs over the past year, with vulnerabilities topping the list at 41%, followed security aspects of their API programs. Nearly half of respondents cited security gaps as their top
closely by authentication problems at 40%. Of more concern, 31% had experienced a sensitive concern, with 23% each citing inadequate runtime or production security and insufficient investment
data exposure or privacy incident and 17% had experienced a security breach; such events have in pre-production security.
significant costs and reputational damage associated with them.

In the past 12 months, what security problems have you found in production APIs? What is your biggest concern about your company's existing API program?

Vulnerability 41% 4%
Other It's too cumbersome and
40% slows down delivery
Authentication problem
It doesn't drive enough
Sensitive data exposure/privacy incident 31% observability and control
14%
Brute forcing or credential stuffing 20% 15%
Denial of service 19%
It doesn't invest enough
in pre-production
Breach 17% security
It doesn't adequately 23%
Account misuse/other fraud 17% address runtime or
production security 23%
Enumeration and scraping 11%

None 6%
22%
It doesn't focus enough time
on fleshing out requirements
and documenting

6
The OWASP API Security Top 10 – a critical starting point
66% of attack attempts leverage one or more of the OWASP API Security Top 10 methods, but only 54% of respondents focus on this industry standard

The OWASP API Security Top 10 list is an industry standard in the API space, but it’s a focus When mapping attempted attacks to the OWASP API Security Top 10, we saw a lot of #8 Simple
area for security programs at only 54% of respondents’ organizations. This low percentage is Injection Attacks (29%) – which represents a carryover from the standard OWASP list. The next
disheartening, since Salt customer data shows that 66% of all attack attempts leverage at least most common attacks were #7 Security Misconfiguration (23%) and #4 Lack of Resources and Rate
one of these 10 security vulnerabilities. Typically, bad actors use combinations of these 10 attacks Limiting (20%). Lack of resource and rate limiting is an API issue that requires that attack activity be
to propagate more sophisticated attacks. With such a large percentage of attacks taking advantage investigated at the user level vs. the aggregate level, a nuance traditional tools like WAFs simply can’t
of these most common and well-documented security flaws, organizations cannot afford to distinguish.
overlook this fundamental principle in API security.
We also uncovered more sophisticated, drawn-out attacks like Broken User Authentication (9%) and
This list was introduced in 2019 and is being refreshed for 2023, so we eagerly await the next set Broken Object Level Authorization (7%). These attacks take advantage of business logic gaps, and
of survey results, and we hope to see this update increase both awareness and focus. the resulting exploitation potential is quite high because these attacks simply cannot be detected by
traditional tools.

Has your security team highlighted the OWASP API Security Salt customer data: Attack attempts leveraging the Salt customer data: Attack attempts that map to the
Top 10 threats as a focus area for your security program? OWASP API Security Top 10 vs. other attack types OWASP API Security Top 10

I don't know API1:2019 Broken Object Level Authorization 7%

Did not involve
OWASP API API2:2019 Broken User Authentication 9%
12% Security Top 10
API3:2019 Excessive Data Exposure 3%

34% API4:2019 Lack of Resources & Rate Limiting 20%

7%
54%
API5:2019 Broken Function Level Authorization

33% Yes 66% API6:2019 Mass Assignment 3%

No Involved API7:2019 Security Misconfiguration 23%
OWASP API
Security Top 10
API8:2019 Injection 29%

API9:2019 Improper Assets Management N/A

API10:2019 Insufficient Logging & Monitoring N/A

7
“Zombie” APIs top the list of API security concerns
Fears over account takeover/misuse rank second, with 43% rating it a “high concern”

With significant API security issues happening regularly to survey respondents, it stands to reason Account takeover is also keeping security professionals up at night, with 43% stating it is a high
that they have real concerns about their API security programs. Outdated/zombie APIs top their concern. See the Salt Labs “in the wild” use cases (Page 15) for a deeper understanding of why this
concerns, with 54% indicating that this risk is of high concern. Given significant documentation concern is so well founded.
challenges at organizations (Page 12), it’s highly likely most environments are running APIs that are
not documented, so even though the lowest percentage (20%) cited shadow APIs as a top concern,
the risk in this area is likely higher than many respondents realize.

Rank your top API security-related concerns

Outdated/zombie APIs 54% 20% 26%

Account takeover/misuse 43% 34% 23%

Denial of service 31% 43% 25%

Accidental exposure of sensitive data 27% 35% 38%

Data exfiltration 25% 44% 32%

Shadow/unknown APIs 20% 24% 56%

High concern Some concern Low concern

8
Most API security strategies remain immature
Only 12% of respondents consider their API security programs to be advanced, and 30% admit they’re non-existent or just in the planning stage

With reliance on APIs at an all-time high and critical business outcomes relying upon them, it What’s getting in the way of adopting such strategies? The same three obstacles have topped the list
is even more imperative that organizations build and implement a strong API security strategy. survey after survey – budget (26%), expertise (23%), and people resources (17%). These three have
Unfortunately, only 12% of respondents’ organizations have what they consider to be advanced topped the list in every report save one – in Q3 2021 – when the second-highest obstacle cited was
API security strategies that include dedicated API testing and runtime protection. This number competing priorities.
is up from 10% in Q3 2022, so security teams are making progress in this arena. Another 26% of
respondents believe their API security strategy is intermediate, using application security testing Fortunately, today’s API security solutions do not require much expertise or investment in people to
and API gateways. manage them, and the return on investment is quite high.

On the opposite side of the spectrum, 30% of respondents – all of whom have APIs running in
production – admit they have no current API strategy, with 5% saying such programs are non-
existent and 25% saying they’re in planning.

How would you describe the security strategy for your API development program? What is the biggest obstacle keeping you from implementing an optimal API security strategy?

Non-existent 5% Budget 26%

Planning stage 25% Expertise 23%

Basic (risk assessment, network scanning, manual reviews) 32% Resources/people 17%

Intermediate (app sec testing, gateways) 26% Defined strategy 10%

Advanced (dedicated API testing and protection) 12% Competing priorities 9%

Time 8%

Tooling/solutions 5%

Other 2%

9
What are security teams looking for in an API security solution?
Respondents say they most value the ability to stop API attacks (44%) and identify APIs that expose PII (44%)

API security is taking center stage for many organizations, but what exactly are they looking for? It is also interesting that respondents seem not to value the ability to identify all APIs or streamline API
The capabilities that respondents identified as most valuable were the ability to identify which incident response and investigations. These findings may reinforce that organizations are not aware of
APIs expose PII or sensitive data (44%), stop attacks (44%), and meet compliance or regulatory how many shadow APIs they actually have and may not be very far down the path of operationalizing
requirements (38%). API security.

Respondents considered the ability to implement shift-left API security practices as their lowest
valued attribute, with only 22% citing it as highly important.

How do you rate the value of each of these attributes of an API security platform?

Stop attacks 7% 7% 23% 19% 44%

Identify all APIs, including undocumented APIs 3% 8% 29% 32% 27%

Identify which APIs expose PII or sensitive data 4% 3% 26% 24% 44%

Implement shift-left API security practices 4% 9% 34% 31% 22%

Streamline API incident response & investigations 4% 8% 32% 29% 28%

Defend against the OWASP API Security Top 10 3% 5% 27% 29% 36%

Meet compliance or regulatory requirements 3% 7% 26% 26% 38%

Unimportant Somewhat important Important

10
Traditional approaches to API security are falling short
Only 23% of respondents believe their existing security approaches are very effective at preventing API attacks

As in previous surveys, this quarter’s respondents indicated that they primarily rely on traditional authorization, encryption, and rate-limiting (on a coarse rather than per-user basis). Analyzing log
tools and processes to secure their APIs. However, they don’t believe these methods are files (51% of respondents) to identify API attacks is tedious, reactive, and highly ineffective – attackers
particularly effective, with 77% of respondents saying their existing tools aren’t very effective in will be long gone with valuable data by the time a security analyst can parse log files. WAF alerts (44%
preventing API attacks. of respondents) are known to be ineffective since WAFs use proxy architectures to apply signatures
that detect only well-known attacks such as cross-site scripting (XSS), SQL injection (SQLi), and
While it is true that traditional approaches to API security provide some coarse application JSON injection. WAFs can’t stitch together the data needed to spot today’s API attacks.
protection, they cannot spot – much less defend against – today’s business logic-based API
attacks. API gateways (52% of respondents) employ traditional protections such as authentication,

How do you identify an attack or attacker targeting your APIs? How effective are your existing security tools in preventing API attacks?

7%
Alerts from a WAF or other security tool 44% I don't know
5%
Alerts from an API gateway 52% Not at all effective Very effective

Analyzing log files 51%

23%
Authentication errors 38% Not very effective
17%
We cannot identify API attacks 11%

Other 2%

48% Somewhat effective

11
APIs are changing constantly and documentation is failing to keep up
37% update their APIs at least weekly, but 48% update their documentation less than twice a year

Having a comprehensive view of your API attack surface is widely agreed to be the first step Even if these APIs were initially documented, the frequency of documentation updates does not
to protecting APIs. Unfortunately, respondents tell us that their confidence in a complete and keep up with the frequency of API changes. OAS and Swagger files are updated at least weekly in
accurate API inventory is low, with only 19% saying they feel very confident. 34% are either not only 12% of organizations. 20% update documentation with no regular cadence, and 23% update
at all or not very confident. And 43% fall somewhere in between, saying that they are somewhat it approximately every six months. These gaps reinforce the shortcomings of relying on shift-left
confident in their inventory. practices for securing APIs.

Why? APIs are constantly changing, making them nearly impossible to document well. 37% of
organizations update their APIs at least weekly, up from 32% in Q3 2022. And 9% update their
primary APIs on a daily basis.

How confident are you that your API inventory is complete? On average, how often are your primary APIs updated? How frequently do you update your OAS or
Swagger files?
5%
I don't know I have no idea Daily Weekly
I don't know
Very confident
Less frequently
Not at all confident than every few
8% 9% 5%
months We rarely 15% 12%
11% 19% 9% update

Not very Every few

Weekly Monthly
confident months 28% 25%
23% 19%
No regular
20%
schedule
43% 27% 23%
Somewhat
confident
Every six
Monthly months

12
Security teams have a difficult time understanding which APIs expose PII
Only 18% are very confident they understand which APIs expose PII data

Respondents are less than confident in their ability to recognize what sensitive or personal Unfortunately, the lack of confidence that respondents have in their organizations’ ability to properly
identifiable information (PII) is exposed within their APIs. Only 18% say they are very confident document PII within their APIs is to be expected. The tools they are relying on to discover the
that their API inventories provide enough detail about their APIs and the sensitive data within. sensitive data within their APIs include logs from their API management tools (38%) and developer
On the other hand, 30% admit that they lack confidence in this area. Respondents have maintained documentation (41%), which we already understand are dangerously lacking. It is therefore also not
a similar level of concern about improper PII documentation throughout all of the State of API surprising that 31% have experienced sensitive data exposure (Page 6).
Security reports, having ranged between 20% and 30% over the past two years.

How do you know which APIs expose sensitive data or PII? How confident are you that your API inventory provides enough detail about your APIs, including
exposure of sensitive data or PII?

4%
Documentation from developers 50% I don't know

Our API management tool logs it 45% Not at all confident Very confident

We don't know which APIs expose PII 25% 10% 18%

Other 4% Not very confident

20%

48% Somewhat confident

13
APIs continue on their explosive growth trajectory
59% of respondents now manage more than 100 APIs, and 27% have more than doubled their API count over the past year

APIs fuel today’s digital economy and enable organizations to deliver the services that their Along with outright API number growth, the number of requests sent to respondents’ APIs each month
customers expect. So it’s not surprising that survey respondents tell us they are experiencing has also grown. The number of respondents citing the smallest bracket of API requests (0-10 million
dramatic growth in the APIs they manage. requests per month) is down to 32%, compared to 37% six months ago. On the other end of the scale,
APIs processing more than 500 million requests grew from 11% six months ago to 16% today.
59% of respondents now manage more than 100 APIs, and 25% manage more than 500. This
number is only growing, with 27% saying they have more than doubled their API count over the
past year. Another quarter said their API numbers increased by 51-100%.

How many APIs does your organization develop, deliver, By how much has the number of APIs increased over the How many requests are sent to your
and/or integrate? past 12 months? applications' APIs each month?

5%
I don't know
3% I don't know
4%
I don't know
301%+ More than 1
1000+ 5% billion
1-100 201-300% 8% 12% 0-10 million
9%

501-1000 500 million - 31%

16% 37% 40% 0-50%
1 billion 12%
101-200%
18%

16%
100 million -
33% 25% 500 million 25%
101-500 10 million -
100 million
51-100%

14
Salt Labs research: Vulnerabilities discovered in the wild
Our researchers uncover API security vulnerabilities in 90% of our investigations, and 50% of them should be considered critical

Salt Labs is the research division of Salt Security, and as such our mission is to It is interesting to note that 41% of survey respondents stated that they had
constantly identify and surface API vulnerabilities in major online websites and identified a vulnerability in their production APIs. This number has fluctuated
services. Our researchers are continuously probing these services – old and new, big between 39% and 55% since we began conducting this survey, but Salt Labs
and small, across all geographical regions and business sectors. We opt to publish research indicates this number is substantially higher.
a subset of these important findings as part of our efforts to educate the industry
about API security. One unique and important point to consider when dealing with API security is
that, as opposed to many other fields in security and offensive research, success
In this section of the report, we wanted to augment the survey and empirical data rates (cases in which we found a significant API security issue) are very high. Our
to showcase some vulnerabilities that the Salt Labs team has recently discovered. research team uncovers API security vulnerabilities in 90% of the services we
While these particular vulnerabilities have been disclosed to the companies involved inspect, and 50% of those vulnerabilities are considered critical. If we can find
and the issues have been resolved, we have chosen to anonymize the companies these security gaps, you can bet attackers will too.
and applications – the focus should be on the nature of the security gap, not on a
particular company who had that gap, because our research shows that when one These findings provide yet another very strong indication that API security is one
service has a flaw like one of these, many others do as well. of the most vital security disciplines today and that every organization employing
a web service should make a concerted effort to invest time and resources into
securing their APIs.

15
Found in the wild: a critical BOLA at a household brand

In this case, we inspected a very popular U.S.-based lifestyle service. This service One of these endpoints was actually a GraphQL endpoint (while the rest of the
is being used by millions of people, often on a daily basis. The service follows a published services were exclusively REST-based). Digging a bit deeper into this
pretty similar design pattern as the rest of the services in its business category. This endpoint, we quickly realized that the “Descriptive GraphQL Errors” feature was
design is completely web service-oriented, and it provides a communication channel enabled, which allowed us to quickly and easily map the entire functionality of this
between end-consumers, service providers, and the company itself. endpoint.

Finding an API security issue in this service was quite challenging, as it was After we gained a solid understanding of the endpoint’s functionality, we started
apparent that the service was well-designed and had passed an effective security looking for security issues, and we were able to spot a strong potential for a BOLA.
validation. However, given the nature of rapid API development and how they’re We were able to confirm that a BOLA attack would succeed, which illuminated the
released (i.e., the CI/CD process, with APIs publishing in minutes), keeping pace with significant business impact this vulnerability could have had.
the security validation process for these new API endpoints is very challenging. So
as researchers looking for gaps, we seek out these kinds of endpoints. An attacker exploiting this vulnerability would have been able to extract the entire
user database. The data set included many PII data components, such as full
Our assumption was that at least one of them might lead us to find a substantial and name, address, email address, phone number, partial credit card numbers, shipping
serious security risk – and, we were right. After inspecting some of the JavaScript addresses, and much more. It also included internal service information such as
code delivered as part of the service interaction, we found several endpoints that the roles and permissions defined for each account. The data set contained both
did not seem to have a specific purpose and were not part of the main business customers as well as internal company employees.
logic flows.
A malicious actor finding these gaps, rather than us, would have caused substantial
damage to this service, its customers and employees, and the company’s reputation.
Fortunately, we discovered it first, notified the company, and worked with the team
to quickly resolve the issue and confirm no exploit had taken place.

16
Found in the wild: Broken authentication to open crypto wallets

The volatile crypto market has been a hotbed of innovation and opportunities. With In a “normal” OpenID Connect (OIDC) flow, a user should not be asked to pass username
such meteoric growth (and now compression) over the past years, a completely new or credentials to the web service. Rather, the user is first directed to a trusted third party
market emerged, paving the way for hundreds of new online crypto services, from (Microsoft, Google, Facebook, and so on), which validates the user’s identity, followed by an
online exchanges, marketplaces, online wallets, and many more. out-of-band query by the service itself to confirm the identity. Only once the user’s identity
has been verified will the user be permitted to log in and interact with the service.
The state of the crypto landscape today reveals a rapidly changing market, tapping
new “cutting-edge” technologies while dealing with massive amounts of digital (and While inspecting the OIDC flow in this crypto application, we noticed that the process was
physical) currencies. The rapid pace of development creates an explosive situation indeed following the guidelines. However, for some reason, the steps included the users
in which the chance of finding security issues is high. Many of the security issues transmitting their email directly to the crypto service. Our biggest question was “What
could lead to tremendous losses in scales which we have never witnessed before. would happen if a user tried to manipulate this login process by following the external login
So Salt Labs decided to look deeper into some of the most popular crypto services process while sending a different username to the crypto service?” This manipulation would
found on the Internet today. create a conflict, and we were interested to see how the crypto service would handle this
conflict.
One of these services handles several billion U.S. dollars in digital currency and
serves millions of global users. One area ripe for exploration was its complex login As it turned out, taking this step revealed a very serious security issue. The crypto service
functionality. Login functionality is the first step in a user’s interaction with a service. respected the forged email sent by the user rather than the real user’s identity. In the
Upon successful login, users are identified and gain access to their data, currencies, most simple terms, an attacker logs in to the crypto service using a legit external account.
digital assets, and other service elements. As a result, the login process is one of the However, instead of sending his or her own username to the crypto service, the hacker
most crucial places to protect from a security perspective. sent the email of a victim. The crypto service honored the victim's email address, and the
attacker was now logged into the victim’s account, despite having no knowledge of the
In this specific case, this application’s login functionality included the popular victim’s password or credentials. Once logged in, the attacker could then perform any action
option to “Login via external account.” This functionality is often implemented using on behalf of the victim, including selling/buying currency, transferring currency, and gaining
several de facto standards including OAuth and OIDC. When inspecting the OIDC access to all of the victim’s PII information stored on the crypto service.
functionality implemented by this service, we were quickly able to spot something
very strange. This type of authentication failure scenario could have potentially led to billions of dollars
worth of damage to the service's users and shows how important it is to properly protect
your authentication endpoints and to ensure you have a deep understanding of any new
technology (in this case OIDC) you incorporate into your online service.

17
Recommendations and conclusions
Implications for API security

The results from the Q1 2023 State of API Security survey are clear. Respondents overwhelmingly told us that reliance on APIs is continuing to grow as APIs become ever more imperative to their
organizations’ success. At the same time, APIs are getting harder to protect as current tools and processes can’t keep pace with new attack trends. Organizations must move from traditional security
practices and last-generation tools to a modern security strategy that addresses security at every stage of the API lifecycle and provides a broad range of protections that foster collaboration
across teams. Here are some tips to consider as you build a more robust and manageable API security program:

Define a robust API security strategy Focus on robust runtime security

WAFs and API gateways leave significant gaps when defending against API attacks, so companies No one will ever write perfectly secure code, so runtime protection provides immediate and
need to define and execute an API security strategy that covers the complete API lifecycle and continuous risk reduction. Since every API is unique, bad actors must perform extensive
addresses cross-functional responsibilities. A comprehensive program must include API design reconnaissance to identify vulnerabilities or gaps in business logic they can exploit.
analysis and drift analysis, automatic and continuous discovery, augmented runtime protections, Attackers know how to probe your systems with subtlety, to avoid tripping coarse security
a feedback loop for developers to use runtime insights to harden APIs, training for SecOps teams protections such as rate limiting on WAFs. To see these nefarious but quiet activities, an API
to understand and triage API security incidents, and a clear model for shared responsibility across security platform must be able to capture millions of data points over a long period of time,
functional groups. since API attacks can take weeks and months to unfold. Then, the platform must tap AI and
ML to process all that data in near real time, so it can discern the recon activities of a bad
Assess your current level of risk actor and correlate them into a single attacker profile to avoid alerting on each bad action.
Validate current API designs against API security best practices, checking whether authentication and Such robust analysis requires cloud-scale big data and mature AI algorithms – it cannot be
authorization controls are in place throughout the sequence of API calls for a given business function, achieved with on-prem API security and immature AI and ML.
for example. Launch simulated attacks based on the OWASP API Security Top 10 list to understand
the gaps in protection from WAFs and API gateways. Emulate the tactics of well-known API security Don’t over-rotate on shift-left tactics
incidents of 2022 to see whether similar business logic flaws exist in your APIs. Shift-left and secure build pipeline approaches have their merits. But most API security gaps
can’t be detected as part of pre-prod API testing – they can be detected only in runtime.
Enable frictionless API security across all your application environments Look for an API security platform that complements pipeline testing and OAS analysis with
With APIs being the foundation of all application development today, you can’t afford to leave some robust runtime protection. Shift-left tactics take much longer to deliver value, ultimately
of your environments unprotected. You must be able to apply API discovery and runtime protection offer limited value since they can identify only a fraction of API security gaps, and leave your
on prem and in the cloud and on legacy apps, as well as your container and Kubernetes deployments. security teams dependent on developers to work through a backlog of security fixes. Get
How you connect the API security tooling into your environments is also crucial – avoid inline your APIs protected today with runtime security – then you can make hardening APIs over
deployments, agents, or the need to instrument code to keep your API security platform from being time a realistic goal.
blamed for any application impact.

18
About the data
Insights from nearly 400 security professionals and API developers, plus analysis of real-world API attack attempts

These report findings combine live Salt customer data and the survey responses of 378 The report also includes real-world API attack attempt data from the Salt Security API Protection
respondents. The survey respondents were fairly evenly distributed across a broad range of Platform. This empirical customer data is anonymized, aggregated, and then analyzed by Salt API
job responsibilities, industries, and company sizes. Nearly half (48%) hold roles in security, 19% security researchers to identify critical trends that can help educate the broader security industry.
are executive-level security or IT leaders, and 26% sit within the platform or DevOps teams.
Technology and financial services companies – widely viewed as being at the forefront of API use – Finally, the “in the wild” vulnerability research comes from our in-house research arm. Salt Labs, the
comprise 48% of respondents. Companies large and small were evenly represented. industry’s only dedicated API research team, undertakes projects to more deeply understand the
evolution of API attacks to improve the Salt platform detection models and educate the companies
involved and the industry as a whole.

What area best represents your functional role? Size of company (employee count) Industry

CISO/BISO/VP Security Other Education

Other
10,000+ 1-100 Energy and Utilities
7% 6% 7%
14% C-level/VP
18% 15% 6% Entertainment
DevOps 12% and Media
5001- 7%
10% 10,000
8% Technology 29%
Financial
Security services
Application 8% 18% architect 101-1000 and
security 30% 19% insurance

16% 29%
4% 4%
API platform
16% 1001-5000
Retail 8% 9% Government
Security analyst Manufacturing Healthcare

19
Additional resources
These key assets will help you get even smarter about API security.

A CISO’s Essential Gartner® Innovation Insight The Business Value of API Security for Dummies API Security
Guide to API Security for API Protection API Security Evaluation Guide

20
About Salt Security
Salt protects the APIs that form the core of every modern application.

The Salt Security API Protection Platform secures your APIs across the full API lifecycle. The Salt
platform collects a copy of API traffic across your entire application landscape and uses big data,
machine learning (ML), and artificial intelligence (AI) to discover all your APIs and their exposed
data, stop attacks, and eliminate vulnerabilities at their source. The Salt platform:

Discovers all APIs and exposed data – Automatically inventory all your APIs, including shadow
and zombie APIs, and highlight all instances where your APIs expose sensitive data. Continuous
discovery ensures your APIs stay protected even as your environment evolves and changes with
agile DevOps practices.

Stops API attackers – Pinpoint and stop threats to your APIs by identifying attackers early, during About Salt Labs
their reconnaissance phase, and prevent them from advancing. The Salt platform correlates Salt Labs identifies API threats and vulnerabilities in customer deployments and in the wild.
activities back to a single entity, sends a consolidated alert to avoid alert fatigue, and blocks the Our in-depth API threat research reports document the steps of an exploit, including the
attacker rather than transactions. processes and tooling, to reveal an attacker’s approach, the details of an exploit, the risk
to the business, and the steps an organization can follow to avoid falling victim to a similar
Improves your API security posture – Salt proactively identifies vulnerabilities in your APIs even attack. We also apply our research findings to improve the ML and AI algorithms at the heart
before they serve production traffic. The platform also uses attackers like pen testers, capturing of our API security platform, so that all our customers benefit from our ongoing research. Our
their minor successes to provide insights for dev teams while stopping attackers before they industry reports, such as this State of API Security Report, tap empirical and survey data to
reach their objective. educate the market on API security trends.

21
Securing Your Innovation

STATE OF APISECURITY-03242023 © 2023, Salt Security. All rights reserved.

22