API security maturity model to assess API security posture
As API use proliferates, attackers are targeting them to exploit networks and data. This six-domain API security maturity model can assess weaknesses and vulnerabilities.
As the number of APIs organizations use continues to grow, it becomes even more critical than ever to secure these bits of code that enable software to communicate. To do this, teams must review API use and security controls, which can be done using an API security maturity model.
"Organizations have so many APIs," said Colin Domoney, a security practitioner and author of Defending APIs: Uncover advanced defense techniques to craft secure application programming interfaces. "A decent-sized organization may have a dozen or so apps, but they may have hundreds of APIs. It's simply a scale problem."
Developers can easily create new APIs, but they don't always include security as part of the process, or they implement security incorrectly. This can lead to authentication, authorization and data leakage issues. Domoney said authorization remains the hardest challenge; determining whether users have access permissions is more difficult to solve.
A security maturity model enables organizations to evaluate their current API security protections and vulnerabilities to determine where they can make improvements. Vulnerable APIs have led to multiple high-profile breaches in recent years, including a 2023 T-Mobile breach that affected 37 million customers and an Optus breach in 2022.
In Defending APIs, Domoney covered API security fundamentals, common API vulnerabilities, and methods to attack and defend APIs. He also detailed an API security maturity model that he created while working at API security vendor 42Crunch.
An important part of using the maturity model is inventorying all APIs in use and determining their risk levels. For example, a hotel booking site should be most concerned with DoS attacks.
Read the following excerpt from Chapter 13 of Defending APIs for more information on how to use the 42Crunch API security maturity model below. Download a PDF of the entire chapter to learn how to create and implement an API security strategy.
The 42Crunch maturity model
In my time as a technical evangelist at 42Crunch, I formulated a six-domain API security maturity model that has proved to be popular with customs in determining both their current security posture and their roadmap toward a more secure posture.
The maturity model features a set of activities for each domain, which may exist to varying degrees based on maturity. For this discussion, we will bucket the activities as non-existent, emerging, or established.
Inventory
An up-to-date and accurate inventory is key to maintaining visibility into the exposed risk and attack surface.
The adage "you can't protect what you can't see" applies perfectly to API security. As APIs grow exponentially, fueled by business demand, it is increasingly difficult for security teams to maintain visibility of what APIs exist and what risks they expose.
Three elements are key:
- How new APIs are introduced and tracked in the organization
- Discovering the API inventory by introspecting the source code repositories to discover hidden API artifacts
- Runtime discovery of APIs (via network traffic inspection, and so on)
At the lowest maturity level, only a basic inventory (usually, APIs deemed critical for the business) is maintained via spreadsheet or manual tracking. There is no management of shadow/zombie APIs.
At the emerging maturity level, an inventory is maintained via API management or a centralized platform. A standard process is used for new API development. For an established level of maturity, the inventory is actively tracked via a centralized platform, and shadow and zombie APIs are deprecated and upgraded.
Design
It is significantly more cost-effective to address security issues at the design phase rather than later in the life cycle -- a shift-left approach is key.
A solid API design practice is the foundation of usable, scalable, documented, and secure APIs. Here are some of the key elements of secure API design:
- Authentication methods
- Authorization models and access control
- Data privacy requirements
- Data exposure (explicit/least content/fit for purpose) requirements
- Compliance requirements
- Account reset mechanisms
- Use and abuse cases
- Key and token issue and revocation methods
- Rate limiting and quota enforcement
Additionally, API design teams should perform threat modeling exercises to understand their threat environment and attack surface.
To learn more
about 'Defending APIs,'
click the cover.
At the lowest maturity level, no formal API design process is in place; instead, a code-first method is used. There is usually no upfront consideration of security concerns, threats, compliance, and data privacy.
At the emerging maturity level, APIs are developed using a design-first approach based on OAS definitions. Security concerns are addressed on an ad hoc basis with no standard process. For an established level of maturity, security is a first-class element of API design that includes standard patterns/practices such as threat modeling.
Development
This vital stage is where the rubber meets the road -- developers should ensure they follow security best practices to avoid introducing vulnerabilities into APIs.
A crucial element of secure APIs is the development process, where specifications are implemented in live APIs. Some key considerations here are as follows:
- Choice of languages, libraries, and frameworks
- Correct configuration of frameworks to ensure security best practices are followed
- Defensive coding -- do not trust user input and handle all unexpected failures
- Use central points of enforcement of authentication and authorization -- avoid "spaghetti code"
- Think like an attacker!
At the lowest maturity level, developers are largely unaware of security concerns in API development or approaches to secure code in general.
At the emerging maturity level, developers are familiar with security considerations and use secure coding practices, albeit sporadically. For an established level of maturity, developers are fully versed in secure code and API security topics and proactively seek to use best practices and defensive coding.
Testing
Without adequate API security testing, an organization runs the risk of deploying insecure APIs -- test early, test often, test everywhere.
API security testing is vital to ensure that APIs are verified as secure before deployment. Security testing should be tightly integrated into the CI/CD process and should avoid any manual effort. Tests should be able to "break the build" in the event of failure. The following aspects should be tested:
- Authentication and authorization bypass
- Excessive data or information exposure
- Handling invalid request data correctly
- Verifying response codes for success and failures
- Implementation of rate-limiting and quotas
- Changes in configuration in production environments from their desired target state (so-called configuration drift)
At the lowest maturity level, there is no specific API security testing, with only functional testing in place.
At the emerging maturity level, API security testing largely uses manual testing and lacks automation and CI/CD integration. For an established level of maturity, API security testing is tightly integrated into all stages of the SDLC, and failures can block releases.
Protection
A defense-in-depth approach is the foundation of risk reduction -- regardless of how well-designed your APIs are, they will still be attacked by persistent and skilled adversaries.
Despite the best efforts during the preceding phases of the SDLC, APIs will still come under attack and should be protected via dedicated API protection mechanisms.
API protection should include the following:
- JWT validation
- Secure transport options
- Brute-force protection
- Invalid path or operation access
- Rejection of invalid request data
- Filtering of response data
Protection logs should be ingested into standard SIEM/SOC platforms to ensure visibility of API security operations.
At the lowest maturity level, no specific API runtime protection is implemented; standard firewalls or WAFs are the only protection in place.
At the emerging maturity level, some protection is provided, typically using API gateways to provide basic enforcement of rate-limiting, token validation, and more. For an established level of maturity, dedicated API firewalls are implemented to provide localized protection at the API transaction level.
Governance
Trust but verify -- a robust governance process is essential to ensure that API development observes organizational methodologies.
The final domain of API security is the overall governance process, which ensures that APIs are designed, developed, tested, and protected according to the organization's process.
Governance covers the following principles:
- APIs are consistent -- that is, they use standard patterns for authentication and authorization
- Standard processes, including testing and remediation requirements, are followed to develop new and updated APIs
- Data privacy and compliance requirements are met
- A process is observed for APIs at their end of life to eliminate insecure zombie APIs
- Stakeholders are enabled on API-specific security topics
- Enablement is updated based on emerging threats
- API development is largely ungoverned, with business units each using their own process with no central oversight
At the lowest maturity level, governance addresses only the basic requirements of compliance and regulatory requirements.
At the emerging maturity level, governance is proactive, and APIs are developed to a standard process. For an established level of maturity, deviations are tracked, and discrepancies are addressed.
Kyle Johnson is technology editor for TechTarget Security.
Colin Domoney is a software security consultant who evangelizes DevSecOps and helping developers secure their software. He was previously chief technology evangelist at 42Crunch, where he focused on advocating for secure API development best practices and developing APIs that are secure by design. He is a regular conference presenter and webinar host and is also the curator of the APISecurity.io newsletter.
