State of API Security

Q3 2021

Report by
State of API Security
The proliferation of APIs as the underpinnings of modern applications and data exchange To understand the state of API security today, Salt Labs – the API threat research arm
continues to increase – industry estimates place API traffic at more than 80% of all Internet of Salt Security – initiated and regularly compiles this API security industry report. Our
traffic. Today’s data-driven economy relies on APIs to access and share that data. We all use pioneering research combines survey responses and empirical data from Salt Security
hundreds of APIs everyday – checking the weather, using our Google or Facebook accounts to log customers. The findings reflect the input of more than 200 security, application, and
into a site, collaborating within office suites, booking trips, or banking online. DevOps professionals across companies big and small in a variety of industries across
the globe. Salt Labs is also able to pull in empirical data from the SaaS component of
APIs also fuel the digital transformation of so many organizations, running today’s modern digital the Salt Security API Protection Platform serving our customers – that aggregated and
platforms to accelerate innovation and drive revenue. Developers are increasingly assembling anonymized data rounds out the survey response findings.
applications based on a collection of APIs, enabling reuse and sharing of common services.
This edition of our report, compiled just six months after our inaugural Q1 2021 report,
As the use of APIs and the value of data shared via them have both increased, so has the reveals that significant gaps remain in addressing API security. We know from the news
attraction to attackers. Attackers realize that APIs are often the weakest link in an organization’s headlines that API attacks are on the rise – seeing reinforcing data quantified here is
application security chain, especially since traditional tooling such as WAFs and API gateways sobering. Nearly every organization has experienced an API security incident in the last
can’t protect against API attacks. year, and 11% of Salt customers are having their APIs attacked more than 500 times
every month. Traditional tooling and approaches to securing APIs continually prove
Taken together, the high use of APIs, faster release cycles with agile and DevOps practices, insufficient, and the common assumption that API security is primarily a developer’s
and increased attacker targeting all lead up to APIs presenting an ever-growing risk factor problem is leaving organizations, their partners, and their customers at risk.
for organizations. API-first companies have been early adopters of dedicated API security
platforms to combat this risk and protect their customer and partner data. Unfortunately, other Read on to assess your own organization’s approaches and to identify areas you can
organizations still lag behind, leaving a great deal of systems, applications, and data at risk. prioritize to improve API security to protect your business, partners, and customers.

1
Attacks are increasing at an alarming rate – malicious traffic grew at three times
the rate of overall API traffic in just the last six months
Salt customers have seen monthly API call rates increase 141% while malicious traffic has grown 348%
Looking across our customer base over the past 12 months,
we’ve seen the average number of APIs per customer more than
triple, growing from 28 in July 2020 to 89 in June 2021. Given the
projects customers are embarking on in digital transformation, Salt customer data Salt customer data
it’s no surprise to see averages tick up so much.
Growth in average number of APIs per customer Growth in API call volume vs. malicious traffic
API call volume, in millions Malicious API call volume, in millions
As a consequence of that API growth, the API call volume (avg. per customer, last six months) (avg. per customer, last six months)
we protect on our API Protection Platform is also growing
89 12.22
dramatically. Isolating to the last six months, we’ve seen the )2.6%(
550 12.00
per-customer average monthly API call volume rise from 195
million calls in December 2020 to 470 million calls in June 2021 – 500 10.75

an impressive 141% increase in overall API traffic. 450 9.50

8.14 470
42
)2.2%(
400 8.25
In the same time period, malicious traffic increased from 1.4%
350 7.00
of all traffic in December 2020 to 2.6% of traffic in June 2021. 28 5.36
)2.1%(
370
Mapped to the average overall call volume numbers, this data 300 5.75
means our customers were experiencing an average of 2.73 250 4.50
July Dec July 195 255
million attack calls per month in December 2020, and that 200 3.25
number grew to 12.22 million attack calls per month in June 2020 2020 2021
150 2.73 2.00
2021 – a staggering growth rate in malicious traffic of 348%. )1.4%(

Dec Feb Apr June

2020 2021 2021 2021

2
API security concerns continue to inhibit critical areas of business innovation
Nearly two-thirds of organizations have delayed API rollouts for key projects
Organizations rely on APIs for a broad range of critical business
initiatives. Our survey respondents cited enabling platform or
system integrations (61%), driving digital transformation (52%), Have you ever slowed the rollout of a new application into
and standardizing or improving efficiency of development
efforts (47%) as the most common drivers for using APIs. In fact,
production because of API security concerns? 36%
many organizations end up integrating vs. purely building the no
majority of their APIs. 64%
yes
These critical projects are being delayed by API security
concerns, slowing business velocity. Nearly two-thirds of
respondents (64%) admitted they have delayed application
rollouts over such concerns. Companies rely on application
development to fuel business innovation – this finding alone
should make API security a key priority in any application-
driven organization. What are the main drivers behind the use of APIs in your organization? (Select all that apply)

Without the confidence to deploy new and iterate on existing

API-based applications at the pace the business demands,
Digital transformation initiatives 52%
organizations risk ceding ground to the competition and losing Development efficiencies and/or standardization 47%
customer loyalty.
Cloud migration 39%
Partner enablement 36%
Platform or system integrations 61%
Monetization of functionality or data 18%
3
Security remains the leading concern in API programs
46% of respondents cite security concerns as their top worry
Many companies are still in the throes of developing more
formalized API programs. We asked about a range of potential Has your security team highlighted the
concerns respondents might have about their API programs – OWASP API Security Top 10 threats as a focus
from impact on application delivery to documentation to pre- What is your biggest concern about your company's API program? area for your security program?
prod security to testing. Across six different areas, the two
related to security concerns dominated the responses. Other It's too manual and slows
down delivery
It doesn't drive enough
Worries over a lack of pre-production security was the top observability and control 5% 11%
response (26%), followed closely by concerns about the program
not adequately addressing runtime security (20%). The next
14% 21%
closest area of concern hit considerably lower on the list – not I do not know
driving enough observability and control (14%).
It doesn't include
enough testing 11% 26% It doesn't invest enough in
pre-production security 50%
yes
We take it as a positive sign that organizations see a gap in
security as a critical concern. One easy step an organization 29%
could take to bolster the security aspect of its API program no
20%
would be to educate team members about the OWASP API 13%
Security Top 10 list. Fully half of responding organizations had It doesn't adequately address
no awareness of this API-oriented list of top threats. Using runtime or production security
It doesn't focus enough time on fleshing out
this information to teach and align development, DevOps, and requirements and documenting
security staff about the nature of API attacks could greatly help
address this significant security gap in API programs.

4
Viewing API security as a “shift left” problem is failing, with 94% of respondents
experiencing an API security incident in the past 12 months
A collective 52% of respondents put responsibility for API security on the API team, developers, and DevOps
With APIs taking on an increasingly important role in today’s Third, and most critical, this perspective misses the reality that
applications, and security problems being so prevalent, many APIs require runtime protection and security controls external
organizations are struggling over who should “own” API security. In to the code to be protected. Most commonly, these steps include
Who's primarily responsible for securing APIs?
our survey, 21% of respondents say developers should be the team external identity, authentication, and authorization mechanisms.
that's responsible -- the API team came in a close second at 20%. Many API deployments also use controls within infrastructure
components, such as IP address allow and deny lists or rate limiting Other
Platform or Product Team
We commonly hear the refrain “developers write APIs, so they mechanisms. API attacks often also target business logic flaws – API team
should be responsible for securing APIs.” This perspective is rife these flaws don’t show up using static or dynamic analysis security InfoSec 4% 3%
with problems. First, no developer has ever written perfect code, testing tools. 9% 20%
and expecting such perfection is not just unrealistic but actually
increases the risk to an organization. That perspective might mean Ultimately, the proof is in the pudding – 94% of survey respondents
organizations will skip deploying additional protections such as experienced an API security incident in the past year, and 100% of
runtime security, assuming developers will do everything in the Salt customers experience multiple attacks every month. DevSecOps 16%
build phase. In practice, not all API security problems can be tested 16% AppSec team
for and identified in code prior to runtime. (Please see next page for additional data points.)

Second, many organizations outsource development partially 11%

or fully to third parties. This tactic often results in a compliance DevOps 21%
exercise with vendor attestation, asking that the third party does
what is appropriate to guarantee security of code. The vendor Developers
attestation approach can provide very little risk guarantee for the
owning organization, and third parties will rarely share original
source code.

5
Viewing API security as a “shift left” problem is failing, with 94% of respondents
experiencing an API security incident in the past 12 months (cont.)

In the past 12 months, what security problems have you found in production APIs? Salt customer data
(Select all that apply)
Average number of attacks per month per customer

Vulnerability 55% 1000+

501-1000
Breach 15% 5% 1-10
6%
Sensitive data exposure/privacy incident 19% 22%
Authentication problem 39%
Denial of service 23% 101-500 19%
Account misuse/other fraud 20%
Brute forcing or credential stuffing 16%
Enumeration and scraping 12%
None 6%
48%
11-100

6
WAFs and API Gateways miss the API attackers – only 16% of respondents find
existing tooling very effective in identifying API attacks
Nearly half of respondents are trying to identify API attackers via their WAF or API gateway, and 12% admit they have no way to identify an API attacker
A majority of respondents are relying on analyzing log files to identify API attackers. This after-the- (page 6). WAFs and API gateway lack the ability to build context or correlate activity so they cannot
fact approach is proving woefully inadequate, given that 94% of respondents experienced an API detect API attacks. Another misconception revolves around authentication and authorization –
security incident in the past 12 months. Nearly half of respondents also note they are using alerts people assume these mechanisms keep them safe from an attack. However, Salt customer data
from a WAF or API gateway to identify an API attack. All Salt customers have WAFs, and nearly all shows that 95% of API exploits happened against authenticated APIs. The #1 attack on the OWASP
have an API gateway – yet every Salt customer experiences numerous API attacks every month API Security Top 10 list targets exactly this kind of manipulation.

How do you identify an attack or attacker targeting your APIs? How effective are your existing tools in preventing API Salt customer data
(Select all that apply) attacks?
% API exploits against authenticated vs. unauthenticated APIs

I do not know
Alerts from a WAF or other security tool 49% Very effective

Alerts from an API gateway 49% Not at all effective 14% 16% 5%
4% against
Analyzing log files 54% unauthenticated APIs
Not very
Authentication errors 47% effective 11%
We cannot identify API attacks 12%
95%
against
authenticated APIs
Other 2% 55%
Somewhat effective

7
62% of organizations have no or just a basic strategy in place for API security
A lack of people/resources and budget are the biggest inhibitors to crafting such a strategy
Despite every organization in this survey having dozens of
APIs in production, only 38% of organizations have more than
a basic security strategy for their API program, and 26% have
no strategy in place at all. Only 11% consider their API security How would you describe the security strategy for What is the biggest obstacle keeping you from
strategy to be advanced, with dedicated API testing and API your API development program? implementing an optimal API security strategy?
protection in place.

Why is it so hard for organizations to develop an API security Advanced (dedicated API Other
Non-existent Competing
strategy? The biggest obstacle respondents noted is a lack of testing and protection) Time
priorities
3% 2%
resources/people (30%), followed by budget constraints (24%).
11% 11%
Only 11% of respondents called out a lack of expertise as their Planning stage 12%
biggest inhibitor. 23% Tooling/solutions
4%
Defined strategy
One area some organizations struggle with is API risk 6%
assessment. Anecdotal feedback during this survey process
Intermediate
(app sec testing, 27% 24% Budget
and across customer engagements centers on a lack of gateways)
understanding that APIs represent a disproportionate share of
data and privacy risk. Because APIs provide the path directly to
a company’s crown jewels, attackers are targeting them at ever 30% 11%
higher rates, as seen in the Salt customer data (page 2) and in 36% Resources/people
news headlines. To combat this risk, API-driven organizations Expertise
should be prioritizing the crafting of a robust API security Basic (risk assessment, network
strategy. scanning, manual reviews)

8
Stopping attacks in runtime is the #1 priority for API security
55% percent of respondents cite that runtime protection is the most highly valued attribute of an API security platform
API security platforms can address a broad range of use The ability to identify which APIs expose PII or other sensitive Streamlining API incident response earned the lowest ratings
cases. Survey responses show that users expect a high level data came in a close second, with 52% of respondents citing as a critical capability. The more real-time operational
of functionality out of these platforms. Like in our previous it as highly important – that figure rises to more than 80% of capabilities, such as discovery and data exposure, attack
survey, the ability to stop attacks led the list as the most respondents when you add together respondents who rated it prevention, and improved security posture, along with
highly valued attribute of an API security platform, with 55% of a 4 or 5 out of 5 in importance. This result should come as no compliance, take top billing as critical use cases.
respondents rating it highly important. surprise as organizations increasingly worry about data loss
and privacy impacts from data exposed via APIs.

On a scale of 1-5, how would you rate the value of each of these attributes of an API security platform? (1 is unimportant and 5 is highly important)

Stop attacks 3% 19% 23% 55%

Identify all APIs, including undocumented APIs 4% 28% 35% 33%

Identify which APIs expose PII or sensitive data 5% 13% 29% 52%

Improve security posture 4% 17% 37% 43%

Streamline API incident response and investigations 6% 31% 39% 24%

Cover the OWASP API Security Top 10 4% 29% 34% 33%

Meet compliance or regulatory requirements 3% 20% 31% 45%

1 - Unimportant 3 - Somewhat important 5 - Highly important

9
85% of respondents lack confidence that their API inventory is complete
17% of respondents have absolutely no confidence in or knowledge about the completeness of their API inventory
You can’t control what you can’t see – so goes the oldest saying lacking – no developer loves to do documentation. Another 34% every month – and 6% doing so every day – it’s incredibly
in cybersecurity. Most API security projects begin with a largely rely on their API management platform for their inventory, but difficult for developers to keep up with API documentation
manual discovery exercise because organizations don’t have a every organization also knows developers release API outside updates, which results in a type of environment drift, or more
full accounting of their APIs. those platforms frequently. specifically, API drift.

Given the preponderance of developer tools used to manage Another compounding factor that makes keeping up with Automation is essential for API discovery – both to keep pace
API inventory, with Postman used by 40% of respondents and inventory difficult is the frequency of API changes. With with developer changes and to catch the APIs released outside
Swagger by 28%, it’s no wonder people find their catalogs more than 60% of organizations changing their APIs at least mediation or gateway platforms.

What mechanism(s) do you use to document and inventory

How confident are you that your API inventory is complete? On average, how often do your primary APIs get updated? your APIs? (Select all that apply)

I don't know I have no idea Daily Swagger 28%

Very confident Less frequently than
8% every few months 7% 6% ReDoc 8%
Not at all confident 15%
8% 4%
10% DapperDox
Weekly 20%
28% OpenAPI Generator

Postman 40%
Not very
20% Every few 23%
confident months Application scanning 23%
Config mgmt database 18%
47%
API management platform 34%
Somewhat
confident
28%
Other 8%
Monthly 10
Outdated or “zombie” APIs lead the list of biggest concerns in API security
40% of respondents cite zombie APIs as their top concern, nearly triple the number who cite account takeover as the top concern
A consequential side effect of frequent API changes (page Accidental exposure of sensitive information rated lowest, Concern over shadow APIs also scores low, with only 28% of
10) is that older APIs persist when they should be deprecated. with half of respondents rating it only 1 or 2 out of 6. Such a low respondents rating it among their greatest concerns - 5 or 6
Survey respondents cited the risk of these kinds of zombie rating comes as a surprise, given the recent headlines around out of 6. This result is also a surprise, given how frequently
APIs as their number one concern at triple the rate they cited leaky APIs in the Experian, Peloton, and LinkedIn data scraping Salt teams find 40% to 900% more APIs than companies have
unknown, or shadow, APIs as their biggest concern. Frequent incidents, and this result contradicts the survey data around documented. A possible explanation is that survey respondents
updates to applications is the biggest culprit in generating what people look for in an API security platform. feel that their API inventory and API documentation processes
these zombie APIs. are more effective than reality merits.

Please rank the following risks, with 1 being your least concern and 6 your greatest concern, related to API security

Shadow/unknown APIs 22% 21% 15% 13% 18% 11%

Accidental exposure of sensitive information 24% 26% 16% 13% 10% 10%

Data exfiltration 16% 12% 31% 16% 16% 9%

Denial of service 15% 13% 13% 28% 17% 14%

Account takeover/misuse 7% 17% 18% 18% 24% 16%

Outdated/zombie APIs 14% 10% 8% 12% 16% 40%

1 - Least concern 6 - Greatest concern

11
85% of respondents lack confidence that they know which APIs
expose sensitive data
15% of respondents have no confidence in or knowledge about which APIs reveal sensitive data
As important as it is to know all the APIs that are running in
your organization, it’s equally important to understand which of
those APIs expose sensitive data such as personally identifiable How confident are you that your API inventory provides
information (PII). 15% of respondents admitted to having no
enough detail about your APIs, including exposure of sensitive Salt customer data
confidence or knowledge about whether their API inventory is
data or PII? Number of APIs that expose PII or sensitive data
complete in this crucial dimension.

Given the preponderance of APIs in the Salt customer base

that do expose sensitive data – 95% of all our customers’ APIs
I don't know
Very confident 5%
Not at all confident 4% do not expose PII or
– getting a handle on this critical security element should be
11% 15% sensitive data
a priority. Like with API discovery, sensitive data discovery
should also be automatic, since APIs are releasing and changing
frequently.
Not very
confident 17%

95%
expose PII or sensitive
53% data

Somewhat
confident

12
Change is coming! Two-thirds of respondents say Security and DevOps Teams
are collaborating or combining
API attacks are increasing and security gaps persist, but greater collaboration should bring improvements
Organizations are already seeing changes in how security teams
approach their partnerships with DevOps teams.

How do you feel API security is creating changes in how security professionals do their jobs?
One-third of respondents cite the need for security to
collaborate more with their peers on the DevOps side, and
another third say security engineers are already getting API security has not changed how
embedded with DevOps teams. Both of these approaches can security teams do their jobs
help improve API security, as long as organizations don’t go too
far in pushing API security as solely a “shift left” mandate (page SecOps teams and SOC analysts are 9% Security must collaborate more
5). having to triage incidents
7% with DevOps teams

Unfortunately, only 16% of organizations are seeing DevOps 34%

teams ask for input from security teams on API guidelines – as DevOps is asking for
security teams come up the education curve on the OWASP API Security's input on API 16%
Top 10, they should be able to provide valuable insights to better guidelines
harden and protect APIs.

Only 9% of respondents see no change in how security

teams are approaching their work in the face of API security
requirements. With each new wave of application security
34%
and infrastructure security trends, adjustments like these
Security engineers are getting
team dynamics take some time to evolve, and a better security embedded with DevOps teams
outcome is always the result.

13
Implications for API security
The increasing frequency of API attacks and the high rate of API security incidents we see across Organizations must move from traditional security practices and last-generation tools to a modern
survey results and the data from the Salt API security SaaS platform make it clear that organizations security strategy that addresses security at every stage of the API lifecycle, provides a broad range of
are falling short in their efforts to mitigate the security risk that APIs present. protections, and fosters collaboration across teams.

1. Augmenting WAFs and API gateways is essential 4. You can’t prevent attackers from targeting APIs, but you can stop
With every Salt customer having a WAF and most also having API gateways, and all of them enduring multiple them before they succeed
attacks per week, we can see the ineffectiveness of these last-generation tools. Organizations hoping they’ve "got
Hackers have realized APIs are like bank routing numbers – they map out the path to all the critical data and
it covered" with these older technologies are exposing their companies to unnecessary risk.
services companies provide to their customers and partners. We should expect hacker attention on APIs only to
increase in coming years. But API attacks are different from typical breaches – it’s not a “one and done” exercise.
Attackers need to poke and prod to learn the business logic built into APIs, and API security tooling can detect
2. An overreliance on “shift left” tactics is not working this reconnaissance activity to effectively block attackers before they reach their objective. Don’t worry about a
As with many application security projects, API security is often seen as the responsibility of development teams. few minor successes by hackers. This approach doesn’t make API security “reactive” – it’s simply how you combat
API attacks, however, target vulnerabilities in business logic, and such flaws do not show up in static code analysis these “low and slow” attacks.
or other dev-stage testing. The refrain is becoming “shift left and protect right” – organizations need the runtime
protection of API security platforms to fully protect their vital data and services.
5. Given the need for automation, with ML and AI, “time in market”
3. A full lifecycle approach is essential is critical
Humans simply can’t keep up in the battle to protect APIs. Attackers are using automation, so the security
Organizations need to improve security at every phase of the API lifecycle and should especially ensure
tooling must as well. Both ML and AI are crucial to API discovery, seeing where APIs expose sensitive data, and
protection against vulnerabilities in production. Organizations should vet APIs as they're developed, automate
– most critically – detecting and stopping attackers. The algorithms at the heart of these platforms rely on time
pre-production scanning in build pipelines, apply thorough manual testing as time permits or as mandated by
in market, and seeing hundreds of customer environments, to improve learning and tune results. Organizations
regulation, and also deploy runtime protection. To enable an environment of continuous improvement, an API
evaluating API security platforms need to understand how long the algorithms have been learning to gain
security platform should also provide closed-loop feedback, tapping the minor success of attackers to distill
insights into their quality and efficacy.
feedback for developers so they can remediate vulnerabilities, harden APIs, and improve API security posture.

14
 Demographics
These report findings are a combination of empirical data from Salt Security customers and the survey responses of over 200 respondents. The survey respondents are well distributed across a range of job
responsibilities, industries, and company sizes. Almost half (48%) hold roles in security, 35% are CISOs, CIOs, or other C-level executives, and another 25% sit on platform or DevOps teams. Technology, financial
services, and insurance companies – widely viewed as at the forefront of API use – make up over half (54%) of respondents. Companies large and small are evenly represented.

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

Other Education
1-100 CISO/VP Security Other Energy/Utilities
10,000+ 6% 3%
13% 12% 15% 15% 5%
Entertainment
24%
DevOps CIO or other
16% 15% C level Financial
24% 101-1,000
21% services/
Insurance
5,001-10,000
10%
10% 5% 35%
Application BISO Technology
security 7%
29% 9% 18% 6% Healthcare
2%
API Platform Security Manufacturing
1,001-5,000 Architect Media

15
About Salt Security
Salt Security protects the APIs that form the heart of every modern application.

The Salt Security API Protection Platform is the industry’s first patented solution to prevent
the next generation of API attacks. Only Salt delivers the context you need to protect your
APIs across build, deploy, and runtime phases, using machine learning and AI to automatically
and continuously identify and protect APIs. Deployed in minutes, the Salt platform learns the
granular behavior of your APIs and requires no agents, configuration, or customization to
pinpoint and stop API attackers.

The Salt platform provides three critical advantages that enable complete protection of APIs Ready to see Salt in action?
across across the full development lifecycle: Request a personalized demo to see
how the Salt Security API Protection
• Complete coverage – we cover all your APIs across all your environments, including load Platform can protect the APIs at the
balancers, API gateways, WAFs, and Kubernetes clusters, running on prem or in the cloud. heart of your business innovation.
And we deploy with no agents, no application or network changes, and no configuration.

• Big data and AI engine – every one of your APIs is unique. Salt understands the unique logic
of your APIs. We apply ML and AI to baseline your APIs and isolate anomalies, differentiating [email protected]
between “different” and “malicious.” All without false positives. www.salt.security
• Context-based protection – Salt combines our ubiquitous coverage and big data engine
to discover all your APIs, see the sensitive data they expose, find and stop attackers, and
capture remediation insights for dev teams to improve API security posture.

16
17