API Security

Maturity
Model
WHITE PAPER
Salt Security API Security Maturity Model

Maturity models are useful for analyzing the current state of an organization’s
team structures, processes, and tooling. They are also helpful for creating
customized roadmaps of short-term and long-term goals for all types of
programs around technology or security domains. Security maturity models
often cited in the application security space often include Building Security
in Maturity Model (BSIMM) and OWASP Software Assurance Maturity Model
(SAMM).

Application security is just one facet of API work, and API security strategy
must also include other security elements such as IAM, network security,
infrastructure security, and mobile security. Creating a maturity model is not
simply an exercise in heavy use of “find and replace’’ with other models for
terms like “application” for “API.” API security strategy spans a mixture of non-
security and security practices that cross many traditional domains.

API attack patterns also differ from attacks against traditional applications.
Existing security controls lack API context and fail at detecting the various
forms of API abuse, exploits, and exposures. APIs are now the most attractive
target for attackers, and organizations need to mature their security
programs to address this current state.

Salt | API Security Maturity Model 2

 How to use the model

The Salt API Security Maturity Model was created intentionally to be simple
rather than exhaustive – some other models contain hundreds of activities.
Why? A simpler model is easier to digest and apply, and the industry
overall is still relatively young and immature. This model will evolve over
time as maturity improves, and we developed the foundations with future
benchmarking in mind.

You’ll find an array of tables in the appendix that detail the various
measurements used to construct the maturity model. Use the instructions
there for self-assessment and benchmarking. The tables can help you
evaluate your organization’s API security practices, determine maturity stage
placement, and identify areas of strength or weakness.

The model includes five levels or stages that map the relative progression
and maturity of organizations. They are:

• Stage 1 – API learning

• Stage 2 – API piloting

• Stage 3 – Limited API deployments

• Stage 4 – Expansive API deployments

• Stage 5 – API first and cloud-native

Each stage contains two sub-groupings of measurements:

• API Barometer measures common non-security traits or indicators

such as levels of API acquisition, integration, or creation and respective
protocols.

• API Security Practices and Tooling measures common security traits or

indicators seen in organizations such as use of security testing tooling or
runtime protection capabilities.

As with any maturity model, landing in a lower stage doesn’t mean your
organization is destined to remain a laggard. Conversely, placing in higher
stages doesn’t mean you’ve solved all procedural or technical problems.
Realistically, organizations move up or down over time as API teams staff up,
new API projects begin, efforts get outsourced, or new partners come into an
organization’s API ecosystem.

Salt | API Security Maturity Model 3

 Stage 5: API-first
Stage 4: Expansive and cloud-native
Stage 3: Limited API API deployments
Stage 2: deployments API Barometer
Stage 1: API piloting API Barometer • Cloud-native and
API learning API Barometer • Pockets of cloud- API-first
• Develop custom and native design and • Creating gRPC and
API Barometer
web mobile apps microservices GraphQL APIs
API Barometer • Develop some REST architecture
that use REST APIs
• Web app-centric APIs for integration
• Formalized build • Formalized build
design and data exchange API Security Practices
pipelines for some pipelines for all API
• Learning API-centric and Tooling
• Acquisition focused API code code
design • Threat protection
from next-gen
API Security Practices API Security Practices API Security Practices firewall (NFGW), web
and Tooling API Security Practices and Tooling application firewall
and Tooling
and Tooling (WAF), API gateway,
• Threat protection • Threat protection • Threat protection
from next-gen • Threat protection from next-gen and/or API security
from next-gen
firewall (NFGW) or from next-gen firewall (NFGW), web platform for external,
firewall (NFGW), web
web application firewall (NFGW), application firewall internal, and third-
application firewall
firewall (WAF) for web application (WAF), API gateway, party APIs
(WAF), API gateway,
business-critical firewall (WAF), and/ and/or API security • Detection of
and/or API security
applications or API gateway for platform for external deltas between
platform for some
business-critical APIs and high-value, intended design and
• Out-of-the-box external, business-
applications internal APIs production API traffic
signatures and rules critical APIs
for threat protection • Minimal tuning of • API code is analyzed • Mediation of all
• Regular tuning of
signatures and rules with all appropriate API calls using
• Security attestation signatures and rules
for threat protection security testing tools unified policies in
from suppliers for threat protection
• APIs are documented • API inventory API gateways and
• Manual API • Formalized API
but not using augmented with microgateways
inventory from asset schema definition
schemas schema ingestion • Strong access
databases and maintenance
• API inventory and/or API discovery controls with OIDC/
• Minimal mediation • API code is
augmented with • External APIs are OAuth2 and secure
and access control analyzed with some
network scanning mediated with traffic extensions like PKCE
from network application security
elements • Network access testing tools management and • API-centric DFIR
control focus and access controls in and integration
• Traffic management • API inventory
segmentation of APIs API gateways with organizational
focus for external augmented with
• Minimal API security • Additional anti-abuse SecOps systems
APIs application security
testing through scanning for external APIs only • OWASP API Security
network scans • APIs are mediated • OWASP API Security Top 10 and anti-
• Additional API Top 10 issues abuse mechanisms
with API gateways
mitigated for all APIs for all APIs
mediation with API for observability
gateways or other • OWASP API Security
network elements
Top 10 issues
• Evaluating API mitigated for external
security tooling or APIs only
platforms

Salt | API Security Maturity Model 4

 Stage 1 - API learning
1
Organizations at Stage 1 can best be described as API learners. They are
becoming aware that APIs are the main vehicle for application design, cloud
enablement, data exchange and a host of technical enablers for modern
system design. Organizations of lower maturity sometimes purposefully
neglect APIs in favor of other technology focus areas such as networks,
infrastructure, or endpoints. Or the organization may simply be unaware
of the prominence of APIs and the resulting attack surface. Stage 1
organizations have acknowledged this gap and are educating teams on API
engineering practices, ideally with security in mind.

Stage 1 API Barometer

Common non-security API traits for Stage 1 include:

• Web application-centric design – these types of applications are

sometimes described as monolithic, but they still make use of web
communications (usually via HTTP) to provide functionality and serve
data. Application designs may rely on static site content or server-side
dynamic web pages like Java Server Pages (JSP) and Active Server
Pages (ASP) that dominated the technology landscape in the 1990s and
2000s. Many of these technologies still remain in operation, though rarely
are new projects initiated using them. Creation of web APIs for Stage 1
organizations is typically avoided as a matter of course as it ramps up
on modern design patterns, or application designs may rely on older API
protocols like SOAP.

• Acquisition focused – the organization may purposefully avoid trying

to build any type of applications or APIs. This characteristic is more
prominent in certain industries like healthcare or education. Even for
these organizations though, technology evolution and customer demand
for modernized user experiences can make it feel like they’re trying to
hold back the tide of progress. Acquired applications and services may
contain or make use of APIs, but it’s not something Stage 1 organizations
focus on heavily.

Salt | API Security Maturity Model 5

 Stage 1 API Security Practices and Tooling

Common security practices and tooling for stage 1 include:

• NGFW or WAF threat protection – next-gen firewall (NGFW) or web

application firewall (WAF) instances are used as runtime protection for
business-critical applications. These controls may be appliance-based,
virtualized, CDN-delivered, or cloud-delivered. The NGFW or WAF is
expected to cover API traffic as part of regular web traffic or multi-
protocol inspection. Threat protection is limited to mitigation of well-
defined web application exploit patterns such as XSS and SQLi.

• Out-of-the-box signatures – rules for runtime protections from NGFW

or WAF are left as is from the vendor with little customization or tuning.
The organization may also opt-in to a vendor-managed service such as
managed security services provider (MSSP) or cloud WAF with managed
rulesets.

• Supplier attestation – suppliers of data, applications, services,

and networks are expected to do their own security testing and
implementation of security controls. The organization seeks to obtain
proof such as through third party audits, security test results, or
certification against standards like ISO or SOC.

• Manual API inventory – the organization’s API inventory or catalog is

derived from asset management databases, configuration management
databases and manually maintained application inventory. Data sources
are typically static and manually maintained.

• Minimal API mediation and access control – the organization uses pre-
existing network elements such as network load balancers (NLB) or
application delivery controllers (ADC) to enforce network access control,
authentication, and authorization on a few of its APIs.

• Traffic management focus for external APIs – externally exposed or

Internet-facing APIs are prioritized within the security program. The
organization makes use of static IP address allow and deny lists as well
as static rate limits.

Salt | API Security Maturity Model 6

 Stage 1 Key Takeaways and Security Gaps

Organizations at Stage 1 are actively learning about APIs, and most will
quickly move to Stage 2, piloting some APIs. Security gaps that often arise at
this stage include:

• API inventory is inaccurate – the organization struggles to understand

its API attack surface and document APIs manually. While no APIs may
be actively developed within the organization, inevitably some APIs are
already in place as a result of acquisition or partner integrations.

• No ability to detect API flaws – vendor and supplier attestations provide

little guarantee that applications and APIs aren’t flawed or vulnerable
to attack. APIs may be leaking sensitive data that can result in privacy
impacts, or APIs may be exploitable and abusable that can lead to
privilege escalation, account takeover, remote code execution, and data
loss.

• Inadequate runtime protection for APIs – traditional security controls

such as NGFW and WAF can be helpful for protecting a broad swath
of protocols and applications if maintained properly, but API protection
inevitably requires more than what is provided by threat protection
features of these traditional network security elements – they have
no ability to maintain context over time and so cannot detect the
reconnaissance behaviors that are precursors to API attacks.

Salt | API Security Maturity Model 7

 Stage 2 - API piloting
2
Organizations at Stage 2 have started educating teams on the basics of APIs
and have initiated small pilot projects for APIs. This API adoption is usually
in the form of integration work between pre-existing systems to improve
functionality or facilitate data exchange. API development may also occur
within low-code application platforms if piloting efforts are focused on
building APIs from scratch and development staff is in short supply. For larger
enterprises with dedicated development teams, the organization may start
to dedicate some employees to API development or operations to the pilot
projects.

Stage 2 API Barometer

Common non-security API traits for Stage 2 include:

• Focus on integration with REST APIs – REST API designs dominate

much of the API landscape and for good reasons. They are suitable
for a number of use cases and design patterns are well-understood.
Supporting technology and guidance on how to use that technology
is also plentiful, meaning startup costs are low and lead time can be
minimal for getting started with API initiatives. The organization focus
is likely to facilitate integration between pre-existing applications and
systems, adding functionality or facilitating data exchange to improve
user experiences. Integration work may also satisfy new business use
cases for powering workflows and “stitch-together” functionality of
disparate systems that expose APIs. This latter use case may be in the
form of webhooks that are useful for automation and triggering functions
based on events.

• Learning API-centric design – while much focus is on REST API

or webhook integration work, the organization is also considering
API-centric design often intertwined with the desire to embrace
microservices architecture (MSA) or container platforms like Kubernetes.
This decision may be inspired by a desire to improve delivery speed or
reduce operational headaches often associated with monolithic designs
and traditional data center focuses. The end goal for the organization
need not be API-first or fully cloud-native. For many organizations, the
desired end-state is likely a mixture of microservice and monolithic
design, and likely supported by hybrid cloud infrastructure.

Salt | API Security Maturity Model 8

 Stage 2 API Security Practices and Tooling

Common security practices and tooling for stage 2 include:

• Additional threat protection from API gateways – in addition to NGFW

or WAF deployments for business-critical applications, the organization
also makes use of API message inspection and filtering capabilities of
their API gateway or API management suite. Gateways may be appliance-
based, virtualized, CDN-delivered, or cloud-delivered. Threat protection
is limited to mitigation of well-defined API exploit patterns such as JSON
and XML injection in addition to common web application exploit patterns
like SQLi and XSS.

• Minimal signature and rule tuning – the organization tunes some

rules and signatures for its API gateways, NGFW, or WAF but leaves
most settings at defaults, relying on the vendor for regular updates.
Tuning, if done, is largely a manual process and may be addressed by
security teams or application teams. The tuning may not be handled
collaboratively.

• API documentation process – the organization has standardized

processes around API documentation and requires development teams
to complete the activity for API delivery. The resulting documentation
artifacts are traditional, human-readable document types as opposed to
API-specific, and machine- readable schema definitions that aid in other
lifecycle activities.

• API inventory augmented with network scanning – the basis for the
organization’s API inventory is still predominantly asset management
databases, configuration management databases and manually
maintained application inventory. The organization also supplements the
API inventory with dynamic data from network scanning, infrastructure
scanning, or vulnerability assessment scanning.

• Network access control focus – the organization focuses heavily on

enforcement of consistent network access control to segregate internal
and external API traffic. API calls from external (Internet-originated) API
callers must flow through monitored, perimeter network elements and
outer API gateway instances. Internal API calls flow through inner API
gateway or API microgateway instances, and it’s not possible to call
internal APIs directly.

Salt | API Security Maturity Model 9

 • Minimal API security testing through network scans – APIs are
tested using “blackbox” methods and probing API endpoints with
network vulnerability scanners. Ideally, these scans use authenticated
context, but the organization may still perform the bulk of scanning
unauthenticated. API call sequences are not considered.

• Additional API mediation with API gateways or other network elements

– the organization mediates more of its APIs with network elements and
is also likely making use of API gateways to enable some mediation.

• Evaluating API security tooling or platforms – the organization

recognizes that current security technology doesn’t scale or address all
API security gaps and has begun evaluating additional tooling options.

Stage 2 Key Takeaways and Security Gaps

Organizations at Stage 2 have begun limited pilots of APIs, which may be

focused on integration work or development within low-code application
platforms. Significant API security concerns are surfacing, causing the
organization to evaluate dedicated API security tooling. Security gaps that
often arise at this stage include:

• Ineffective API inventorying and testing – the organization uses network

scanning to identify and test API endpoints. While useful for collecting
infrastructure and host information, these tools fail to test APIs in
depth or gather relevant API metadata. The problem is worsened if the
organization is not performing authenticated scans.

• Reliance on network access control, which leaves APIs exposed – most

organizations struggle to document APIs, which is a prerequisite for
enforcing even basic access controls. The problem is worse with manual
documentation which can’t scale and doesn’t provide machine-ingestible
schema definitions.

• Message filtering, which offers limited threat protection – API gateways

offer message inspection and translation to support many use cases
like request or response modification, token translation, and protocol
bridging. The core function of API gateways is to support mediation for
observability and access control. Message filters provided by vendors
that are repurposed as threat protection cover only known or overly
generalized injection attack patterns, and API gateways can quickly
become overloaded if enabled.

Salt | API Security Maturity Model 10

 Stage 3 - Limited API deployments
3
Organizations at Stage 3 have established baseline knowledge of API design
patterns. Teams are actively creating new web or mobile applications that
leverage APIs. Or teams are creating new APIs as products unto themselves
to satisfy internal employee use cases or fully monetized for external
customers or suppliers. For smaller organizations, development and security
tasks are usually shared responsibility with other work. Larger enterprises
have likely formed dedicated API product teams or have plans to do so. At
this stage, DevOps practices with standardized build pipelines for APIs are
certainly in play and can quickly become a prerequisite in order to scale API
delivery.

Stage 3 API Barometer

Common non-security API traits for Stage 3 include:

• Custom application development powered by REST APIs – the

organization is actively designing and coding web and/or mobile
applications using modern technology stacks. Front-end code for web
applications is JavaScript based using Angular, Node, React, or other
modern JS technologies. Mobile applications may be hybrid or full rich
clients depending on how much mobile device capability is necessary. All
front-end application types rely heavily on back-end REST APIs to power
functionality or exchange data. Back-end APIs may still utilize traditional
design patterns and live within traditional data centers, or they may be
cloud-hosted.

• Formalized build pipelines for some API code – continuous integration

(CI) and continuous delivery (CD) processes are standardized for some
API code. CI/CD build pipelines are foundational to DevOps practices,
helping to facilitate rapid delivery as well as consistency, auditability,
and automatability. The organization is likely starting to educate on other
DevOps practices such as test automation and defining systems as
infrastructure-as-code.

Salt | API Security Maturity Model 11

 Stage 3 API Security Practices and Tooling

Common security practices and tooling for Stage 3 include:

• Additional threat protection from API security platform – in addition to

NGFW, WAFs, and/or API gateways, the organization has adopted an API
security platform that can integrate with various elements of enterprise
architecture to gather API telemetry, detect API issues, stop API attacks,
and continuously advise on API security posture improvements. The
organization uses the API security platform primarily to protect some of
its external, business-critical APIs.

• Regular signature and rule tuning – the organization regularly tunes

rules and signatures for its API gateways, NGFW, or WAFs as part of API
delivery. API profiling and rule tuning may be automated, particularly
when paired with dedicated API security tooling. Tuning may also be
augmented with manual processes, with security teams and application
teams working collaboratively.

• Formalized API schema definition and maintenance – the organization

has standardized processes around API documentation as part of API
delivery. The resulting documentation artifacts are API-specific, and
machine-readable schema definitions that aid in other lifecycle activities
such as Swagger, OpenAPI Specification (OAS), and GraphQL schema.

• API code is analyzed with some application security testing tools –

organizations often focus on static application security testing (SAST)
if they have access to original source code and working relationships
with development teams. API schema analyzers may also be in the mix
as another form of static analysis. Dynamic application security testing
(DAST) may be preferred if security teams come from a network scanning
background, don’t want to burden development teams, or prefer to test
running code via API endpoints for exploitable conditions. Software
composition analysis (SCA) may also be used to validate whether
known vulnerable dependencies are being included in API source code.
Organizations at this stage are likely running two security testing tools at
most, usually SAST+SCA or SCA+DAST, but not utilizing the full range of
testing types.

Salt | API Security Maturity Model 12

 • API inventory augmented with application scanning – the organization
supplements the API inventory with dynamic data from application
security testing tools or other application-layer discovery as opposed to,
or in addition to, network scanning.

• API mediation with API gateways for observability – APIs are mediated
for improved observability and monitoring. The mediation is primarily
for non-security use cases such as measuring availability or monetizing
APIs. The organization may also be relying on API gateways to perform
API schema enforcement, validating that API calls conform to API schema
definitions.

• OWASP API Security Top 10 issues mitigated for external APIs – many
organizations will prioritize Internet-facing or customer applications as
the biggest security risk and business risk. The same holds true for APIs,
though more appropriate labels include public, external, and outer APIs.
Specifically, the organization is concerned with mitigating the Top 10
API security issues as defined by OWASP. Some internal APIs may be
included sparingly if they are in scope as part of regulation like GDPR or
standards like PCI-DSS.

Stage 3 Key Takeaways and Security Gaps

Organizations at Stage 3 are actively creating applications and APIs, and they
are embracing DevOps practices to enable or speed up API delivery. Security
gaps that often arise at this stage include:

• Internal APIs lack threat protection – with the prioritization of security

work on external APIs, internal APIs still remain vulnerable. This focus
makes detection of complex attack chains that traverse external APIs to
internal APIs more difficult. This focus also leaves direct internal API calls,
inner API to inner API communication, and internal systems vulnerable.

• APIs may be prone to business logic abuse – SAST or DAST alone is

insufficient to identify business logic flaws since these tools aren’t
designed for it. Schema enforcement by API gateways also doesn’t
help matters, since not all functions or data types for an API need to be
documented. Detection of business logic flaws or abuse rests squarely
on the capabilities of the API security platform or tooling in use.

Salt | API Security Maturity Model 13

 • Static rate limits can’t scale – static rate limiting mechanisms that are
present in most network proxies including API gateways can work well
for small numbers of API callers or low volume requests. Organizations
often need to expose APIs to broader numbers of consumers, different
consumer types, and higher volumes of requests. Static rate limiting
mechanisms are difficult to operationalize in those cases, and they
struggle to stop distributed, advanced API attacks designed to evade
rate limiting thresholds. The organization may be starting to lean more
heavily on dedicated API security tooling to adjust rate limits dynamically
based on behaviors, but such runtime protection may not be deployed
throughout the enterprise.

Salt | API Security Maturity Model 14

 Stage 4 - Expansive API deployments
4
Organizations at Stage 4 are actively creating and integrating APIs as
well as applications that make use of APIs. It has established DevOps
practices across the board with standardized build pipelines for all APIs.
The organization is adopting MSA patterns and making use of cloud-native
technologies including elastic storage, containers, and container platforms.
Containerization helps with packaging API code, iteratively testing code,
ensuring infrastructure consistency, speeding remediation, and enabling
rollback.

Stage 4 API Barometer

Common non-security API traits for Stage 4 include:

• Pockets of cloud-native and microservices architecture – the

organization is using cloud-enabling technologies and newer design
patterns to improve API availability and scalability. Container platforms
such as Kubernetes offerings and application platforms are prominent
in addition to traditional virtualized infrastructure and cloud service
consumption. Serverless technologies are also possibly being explored.

• Formalized build pipelines for all API code – CI/CD processes and build
pipelines are established for all API code. Test automation for APIs should
be well-established, which may still make use of front-end applications
to interact with back-end APIs. DevOps teams or infrastructure engineers
define API infrastructure using infrastructure-as-code formats and tooling
for improved delivery.

Stage 4 API Security Practices and Tooling

Common security practices and tooling for Stage 4 include:

• Additional threat protection from API security platform – as in Stage

3, the organization uses an API security platform to augment the
capabilities of its NGFW, WAF, and/or API gateway instances and improve
threat protection for its APIs. The organization has expanded the use of
the API security platform to protect high-value, internal APIs in addition
to its external APIs.

Salt | API Security Maturity Model 15

 • API code is analyzed with all appropriate security testing tools – SAST
and schema analysis is run at multiple stages of the API lifecycle such
as pre-commit through the IDE or through API design and mocking
tools, on code commit into git-based VCS, and as part of CI/CD builds.
DAST or API fuzzing is run using authenticated scans supported by
appropriate test automation scripting and API schema definitions. API
call sequences may be considered, but it’s likely as a by-product of front-
end interactions with back-end APIs. The organization may also employ
behavior analysis scanning offered by some AST tools in runtime, or they
rely on the API security platform to identify behavior anomalies.

• API inventory augmented with schema ingestion and/or API discovery –

the organization supplements the API inventory by ingesting API schema
definitions and/or using continuous discovery of an API security platform.

• External API mediation and access control with API gateways – in

addition to observability and schema enforcement, the organization is
making extensive use of API gateways for access control of external APIs.
API gateways have consistent configuration for enforcing authentication
and authorization, paired with enterprise IAM systems. API gateways are
also used to manage API traffic, specifically via use of rate limits and IP
address allow and deny lists.

• Additional anti-abuse for external APIs – the organization seeks greater

protection for external APIs beyond those issues defined in the OWASP
API Security Top 10. This collection of concerns includes automated
threats like scraping, aggregating, carding, scalping, brute forcing,
credential stuffing, and other forms of business logic abuse that are
often grouped in with fraud. Such protection is likely powered by an API
security platform, but other bot mitigation, bot management, or anti-
fraud controls may be in use.

• OWASP API Security Top 10 issues mitigated for all APIs – the
organization likely still prioritizes public, external, and outer APIs as the
biggest security risk. The organization also mitigates the OWASP API
Security Top 10 issues for internal APIs to mitigate risks from insider
threats or to detect attacks when API communications traverse external
and internal APIs.

Salt | API Security Maturity Model 16

 Stage 4 Key Takeaways and Security Gaps

Organizations at Stage 4 are actively creating and integrating APIs, and they
have established DevOps practices across the board with standardized build
pipelines for all APIs. The organization is adopting MSA patterns and making
use of cloud-native technologies including elastic storage, containers, and
container platforms. Security gaps that often arise at this stage include:

• Internal APIs may still be prone to business logic abuse – detection of

business logic flaws or abuse rests squarely on the capabilities of the
API security platform or tooling in use. If internal APIs aren’t being closely
monitored, insider threats or complex attack chains may fly under the
radar of security teams putting the organization at risk.

• Differences may exist between API designs and production

deployments – the organization possesses tools that can discover, test,
and protect APIs, but the information isn’t correlated effectively. An
organization should compare its documented design (informed by API
schema definitions) with production deployments to spot holes in its
security posture. Organizations that fully document APIs with schema
definitions still find that they have shadow API endpoints and zombie
API endpoints. API endpoints may exist with undocumented functions,
or data types may not be fully defined, since this is inherent with the
flexibility of API schema. As a result, API runtime protection may not be
configured correctly or cover the entire API attack surface.

• API-centric SecOps is lacking – flaws will be identified within APIs

regardless of how extensive an organization’s testing capacity might
be. This reality is a side effect of limitations of scanning tools, time
needed to test in-depth, and complex API call sequences inherent in
fully integrated architectures. Indicators of compromise and potential
anomalies can be difficult to spot in complex attack chains. It’s critical
that API context is factored into security operations so that teams can
react quickly and effectively to API security events when they arise.

Salt | API Security Maturity Model 17

 Stage 5 - API-first and cloud-native
5
Companies at Stage 5 are currently a relative rarity. Even “born in the cloud”
companies will have difficulty attaining this level, in large part because API
security is a new discipline. Many organizations have a mix of new and old
technology stacks. Monoliths likely need to co-exist with microservices to
maintain service levels, satisfy all business use cases, and meet customer
demand. Cloud-native technologies may be a significant component of
infrastructure but not the entirety. Realities of systems architecture and
technology adoption makes it difficult to achieve this level of maturity across
the board. A direct correlation often exists with how far the organization
has progressed in its digital transformation efforts. It’s a high bar to say the
least, and few organizations will achieve this level when considering all non-
security and security aspects across all environments.

Stage 5 API Barometer

Common non-security API traits for Stage 5 include:

• Cloud-native and API-first design – Kubernetes clusters are likely a

given, and the organization may make use of multiple vendor offerings.
Cloud-scale, elastic storage is necessary for storing the substantial
amounts of data transacted by APIs and maintaining high availability.
The organization is also likely making use of service mesh to intelligently
route and load balance application traffic. Serverless technologies may
also be used to power APIs or related functions that are short-lived, but
APIs are still mediated appropriately.

• Creating gRPC and GraphQL APIs – in addition to REST APIs, the

organization is making use of newer API protocols. GraphQL may be in
use to provide richer experiences to front ends and consolidate back-
end REST API queries. gRPC is used to power internal microservice
communications that require high levels of performance, and gRPC APIs
may also be exposed for external consumers.

Salt | API Security Maturity Model 18

 Stage 5 API Security Practices and Tooling

Common security practices and tooling for Stage 5 include:

• Additional threat protection from API security platform – as in Stage 3

and Stage 4, the organization uses an API security platform to augment
the capabilities of its NGFW, WAF, and/or API gateway instances and
improve threat protection for its APIs. The organization has expanded the
use of the API security platform to protect all external and internal APIs,
as well as provide visibility into third-party API consumption.

• Detection of deltas between intended design and production API

traffic – the organization compares its documented designs from API
schema definitions against production API traffic to identify shadow API
endpoints and zombie API endpoints. Undocumented functions or data
types for respective APIs are relayed back to owning API teams to adjust
API schema definitions, and runtime protections are adjusted accordingly
by security owners.

• Full API mediation with API gateways and microgateways – the

organization is making extensive use of API gateways and microgateways
for observability and access control of external and internal APIs.
Configuration of API gateway instances is also managed centrally
through API management suites to ensure consistency of API security
posture and unified security policy.

• Strong access controls with modern protocols – the organization is

adamant about enforcing authentication on all API endpoints. User
authentication and authorization makes use of modern protocols
such as OpenID Connect (OIDC) and OAuth2, as well as multi-factor
authentication where appropriate. Secure extensions like Proof Key for
Code Exchange (PKCE) may also be in use to bind user sessions to API
clients and mitigate risks of stolen session identifiers and authentication
tokens. Machine communications are also secured with certificate-based
authentication, mTLS, or other strong access control approaches. Access
controls are also paired with behavior analysis, and anomalous activities
detected within sessions result in step-up authentication or session
termination.

Salt | API Security Maturity Model 19

 • API-centric DFIR and integration with organizational SecOps systems –
API context is factored into security operations processes and systems
so that teams can react quickly and effectively to API security events
as they arise. API metadata, information, and events are mapped
to MITRE ATT&CK framework and not just OWASP API Security Top
10 items. Additionally, security event and incident data are fed into
the organization’s SIEM platforms and used in API incident response
processes which may be automated through SOAR.

• OWASP API Security Top 10 mitigation and anti-abuse for all APIs
– the organization mitigates the OWASP API Security Top 10 issues
for all external and internal APIs. The organization also mitigates risk
of automated threats including scraping, aggregating, brute forcing,
credential stuffing, and other business logic abuse for external and
internal APIs.

Stage 5 Key Takeaways and Security Gaps

Security gaps should be minimal at this stage given the host of people,
processes, and technology put in place to enable API security. Continuous
monitoring for new API attacks is a given as the attack surface shifts
constantly, and new attack techniques emerge. Security gaps that may still
arise at this stage include:

• Other aspects of the supply chain may still be weak – the organization
may be secure, but API ecosystems are vast and complex. The
organization likely works with many partners and suppliers that results
in a large digital supply chain. APIs often have other dependencies, and
one API may invoke multiple third-party APIs. The entirety of API call
sequences is likely outside one organization’s control.

• Technology stacks are ever-changing which creates security risk

– the organization must stay abreast of new technologies as API
teams create new functionality. The industry has experienced many
technology evolutions including GraphQL and gRPC. These evolutions
aren’t always well-understood, technical documentation can be limited,
and technologies may not be well-supported by pre-existing security
investments. Organizations choosing to operate newer technology must
continuously train employees and stay current with releases to reduce
some of the inherent risk.

Salt | API Security Maturity Model 20

 • API-centric SecOps is nascent – taxonomies for classifying API issues
and technical guidance for dissecting complex attack chains are limited.
Communicating API issues effectively can be an exercise in confusion
and frustration for practitioners. This disconnect also creates challenges
with implementing appropriate security controls, code fixes, or other
mitigations. Who is the appropriate owner for a problem with an API? Is
the best resolution a code fix, an infrastructure configuration, or some
other mitigation? Should an API security problem map to OWASP API
Security Top 10, MITRE ATT&CK, both, or something else entirely? Adding
fuel to the fire, SecOps teams and SOC analysts are often overloaded
with handling all types of security issues, and API expertise is limited.

Salt | API Security Maturity Model 21

 Summary and Next Steps

Like with other maturity models, security strategy is an ongoing process,

and API security in particular is in its earlier development. Most organizations
are strong in some areas and weaker in others. Many organizations will find
they are in lower stages of maturity when factoring in both the non-security
measurements and security practices. Most will also find they satisfy a
majority of security practices in one level (the stage that is the best fit) and
a smaller set of security practices in the next. This discrepancy is a good
indicator that the organization is advancing in maturity and could advance the
maturity of their API security program by tweaking some processes. Those
organizations that are looking to advance their API security strategy should
look ahead at the other stages for short-term and long-term planning.

Time and effort invested in maturing the organization’s API security program
has amplifying effects. Many of the security techniques and tooling covered
here support other security trends such as risk-based authentication, zero
trust architecture, and digital supply chain integrity. Intersections also occur
with other security program work, including cybersecurity, infrastructure
security, application security, and cloud security.

API security strategy requires continuous self-examination and improvement.

Even if the organization is able to attain Stage 5 maturity, the technology
and application landscape and resulting attack vectors continue to shift.
Processes and toolchains must be adapted as part of the organization’s API
security strategy. Organizations in higher levels of maturity should also help
industry peers and share knowledge to help improve the overall state of API
security.

Salt | API Security Maturity Model 22

 Appendix

The tables that follow detail the measurements for activities, and tools for
each stage of the API security model. These measurements have been
grouped into categories for easier identification and self-assessment, which
are:

• API design, development, and deployment

• API cataloging, compliance, and governance

• API mediation, monitoring, and operations

• API threat detection, protection, and response

The scoring column is used to assess how well the organization satisfies a
given category of activities and tooling on a scale of 1 - 5. If the organization
finds that it is scoring 4 or 5 in a majority of the categories, it’s likely mastered
that stage and ready to advance to the next.

Salt | API Security Maturity Model 23

Stage 1 Details - API learning

Category Activity or Tool Scoring

(1-5)

API design, • The organization focuses on development or acquisition of web or mobile

development, applications, which may include APIs indirectly
and deployment • Security responsibility resides within procurement or governance functions of the
organization
• The organization seeks vendor attestation to guarantee security of code and
satisfy compliance policy

API cataloging, • The organization has limited or no awareness of APIs

compliance, and • API cataloging, if done, is manual and repurposes information from other asset
governance databases

API mediation, • The organization uses limited API mediation, relying on what is provided by ADCs,
monitoring, and CDNs, or NLBs
operations

API threat • The organization front-ends applications with NGFW for broad protection across
detection, all protocols or WAFs to protect web-centric business-critical applications
protection, and • The organization uses out-of-the-box signatures and rules for threat protection
response • The organization restricts calls on external APIs with IP address allow/deny lists
and static rate limits

Salt | API Security Maturity Model 24

Stage 2 Details - API piloting

Category Activity or Tool Scoring

(1-5)

API design, • Application teams develop applications within low code and integration platforms
development, • Application teams build some REST APIs to aid in application integration or data
and deployment exchange
• Application teams are learning modern, API-centric design patterns
• The organization performs limited API security testing with network scanning

API cataloging, • The organization’s API documentation process is semi-formalized but focuses on
compliance, and diagrams or static documents as output
governance • API catalog augmented with network scanning

API mediation, • The organization emphasizes network access control through isolation and
monitoring, and segmentation
operations • The organization enforces authentication and authorization using traditional best
practices

API threat • The organization front-ends applications with NGFW for broad protection across
detection, all protocols or WAFs to protect web-centric business-critical applications
protection, and • The organization enables message filtering and malicious pattern matching offered
response by API gateways
• The organization tunes some of the out-of-the-box signatures and rules for threat
protection
• The organization restricts calls on external and internal APIs with IP address allow/
deny lists and static rate limits
• The organization has begun evaluating API security tooling or platforms

Salt | API Security Maturity Model 25

Stage 3 Details - Limited API deployments

Category Activity or Tool Scoring

(1-5)

API design, • The organization has begun exploring cloud-native design patterns
development, • Application teams develop custom web and mobile applications that use REST APIs
and deployment • The organization embraces DevOps practices and has established CI/CD build
pipelines for some API code
• Application teams promote modern, API-centric design
• Application teams separate design and development of back-end and front-end
code
• The organization uses some application security testing tools, such as SAST+SCA
or DAST+SCA, to analyze security of its API source code

API cataloging, • The organization’s API documentation process is formalized, and application teams
compliance, and regularly maintain API schema definitions
governance • The organization has increased awareness of APIs and improved API catalog
accuracy through application scanning

API mediation, • The organization emphasizes network access control through isolation and
monitoring, and segmentation
operations • The organization enforces authentication and authorization using traditional best
practices
• Application teams mediate with API gateways primarily for observability and
monitoring
• The organization may use the schema enforcement capabilities of API gateways
for those APIs that are mediated

API threat • The organization front-ends applications with NGFW for broad protection across
detection, all protocols or WAFs to protect web-centric business-critical applications
protection, and • The organization enables message filtering and malicious pattern matching offered
response by API gateways
• The organization augments threat protection for external, business-critical APIs
with API security tooling or platforms
• The organization regularly tunes the out-of-the-box signatures and rules for threat
protection, which may be partially automated
• The organization restricts calls on external and internal APIs with IP address allow/
deny lists and static rate limits
• The organization mitigates the OWASP API Security Top 10 issues for external APIs

Salt | API Security Maturity Model 26

Stage 4 Details - Expansive API deployments

Category Activity or Tool Scoring

(1-5)

API design, • The organization uses cloud-native technologies and design patterns for some
development, infrastructure and APIs
and deployment • The organization has established CI/CD build pipelines for all API code
• I&O and DevOps teams are adopting containers and infrastructure-as-code for
provisioning infrastructure that powers APIs
• The organization uses SAST, DAST, fuzzing, and SCA as appropriate to analyze
security of its API source code

API cataloging, • The organization supplements the API catalog by ingesting API schema definitions
compliance, and and/or using continuous discovery of an API security platform
governance

API mediation, • The organization emphasizes network access control through isolation and
monitoring, and segmentation
operations • The organization enforces authentication and authorization using traditional best
practices
• The organization mediates external APIs with API gateways for observability and to
enforce traffic management, authentication, and authorization
• API gateways have consistent configuration for enforcing authentication and
authorization, paired with enterprise IAM systems
• The organization may use the schema enforcement capabilities of API gateways
for those APIs that are mediated

API threat • The organization front-ends applications with NGFW for broad protection across
detection, all protocols or WAFs to protect web-centric business-critical applications
protection, and • The organization enables message filtering and malicious pattern matching offered
response by API gateways
• The organization augments threat protection for external, business-critical APIs
with API security tooling or platforms
• The organization regularly tunes the out-of-the-box signatures and rules for threat
protection, which may be partially automated
• The organization restricts calls on external and internal APIs with IP address allow/
deny lists and static rate limits
• The organization mitigates the OWASP API Security Top 10 issues for all external
and internal APIs
• The organization implements additional protection for external APIs using API
security tooling, bot mitigation, or anti- fraud mechanisms to mitigate threats
beyond those defined in the OWASP API Security Top 10

Salt | API Security Maturity Model 27

Stage 5 Details - API-first and cloud-native

Category Activity or Tool Scoring

(1-5)

API design, • The organization prioritizes cloud-native and API-first design

development, • Application teams embrace newer API protocols such as gRPC and GraphQL in
and deployment addition to REST
• I&O and DevOps teams extensively use containers and infrastructure-as-code for
provisioning infrastructure that powers APIs
• The organization uses SAST, DAST, fuzzing, and SCA as appropriate to analyze

API cataloging, • The organization detects deltas between design time API metadata and production
compliance, and API traffic
governance

API mediation, • The organization emphasizes network access control through isolation and
monitoring, and segmentation
operations • The organization enforces authentication and authorization using traditional best
practices
• The organization mediates all external and internal API calls with API gateways
and microgateways for observability and to enforce traffic management,
authentication, and authorization
• API gateways have consistent configuration for enforcing authentication and
authorization, paired with enterprise IAM systems, and managed through an API
management suite for unified policies
• The organization may use the schema enforcement capabilities of API gateways for
those APIs that are mediated
• Application and identity teams require use of OAuth2 and OIDC with secure
extensions such as PKCE
• Machine communications are secured with certificate-based authentication, mTLS,
or other strong access control approaches
• Access controls are paired with behavior analysis to detect and respond to
anomalous API callers

API threat • The organization front-ends applications with NGFW for broad protection across all
detection, protocols or WAFs to protect web-centric business-critical applications
protection, and • The organization enables message filtering and malicious pattern matching offered
response by API gateways
• The organization augments threat protection for external, business-critical APIs
with API security tooling or platforms
• The organization regularly tunes the out-of-the-box signatures and rules for threat
protection, which may be partially automated
• The organization restricts calls on external and internal APIs with IP address allow/
deny lists and static rate limits
• The organization mitigates the OWASP API Security Top 10 issues for all external
and internal APIs
• The organization implements additional protection for all external and internal APIs
using API security tooling, bot mitigation, or anti-fraud mechanisms to mitigate
threats beyond those defined in the OWASP API Security Top 10
• The organization has integrated API tooling with SIEM/SOAR toolchains to enable
workflows and aid in API incident response

Salt | API Security Maturity Model 28

Securing your
Innovation.