Establishing a Mature API Security Strategy
Application Security
Ryan Siu
7 February 2025
Why is the adoption of an API strategy important?
In order for your APIs to meet the long-term needs of your consumers, it is important for them to be built with sustainability in mind. This translates to a well-defined strategy for preparing their delivery.
​
Companies sometimes skip to the operational phase of the API cycle without planning key details as to how consumers will integrate those APIs and, where relevant, build applications and user interfaces.
How granular should your strategy be?
Brevity of an API security strategy can lead to an organisation wasting time and resources when making decisions on which security controls to implement for their APIs.
It is important that your strategy is not too high-level and has been enriched with technical input from your engineering function. By collaborating closely with your developers, engineers and architects when defining this strategy, you will understand the unique motivators for your engineering capability and the necessary actions you must take to get buy-in from them to support your AppSec initiatives.
Key Areas to Consider in Your API Security Strategy
1
Information Privacy
In concert with other stakeholders outside of your development teams, it is important to perform information privacy reviews of your APIs.
These reviews should include quantifying the impact of a privacy breach on your organisation. The outcomes of this review should drive future decisions relating to the security controls you place around your APIs endpoints.
2
Authentication and Authorisation
Adopting the right authentication and authorisation models will depend on the nature of your API set. You need to define whether your APIs need to be accessed by an authenticated or unauthenticated API consumer.
Given the variety of authorisation models available today, from traditional models (such as Basic and Digest auth) to modern models (including OAuth and AWS Signatures), you should research and ensure the type. For example, you should consider the sensitivity of data your API provides access to, and the types of privileged actions your API can perform.
3
Access
Controls
Defining security and access policies that will be implemented later in the API cycle are critical steps to the longevity of security across your API endpoints. By formalising developer personas in your organisation, you will be able to define the corresponding level of access for each persona in your strategy.
4
Securing API Network Traffic
As part of the threat models you create, it is likely that you will identify use cases for ensuring the availability and robustness of API traffic between your API endpoints and consumers.
​
Depending on the nature of your API endpoints, it may be necessary to enforce quotas or rate-limits to restrict the frequency at which your endpoints can be accessed. In connection with your developer personas and the priority of specific API endpoints, particularly when scalability is a requirement for the API, a tailored quota and rate-limiting ruleset may need to be applied. This would ensure access is granted to the right developers and API consumers.
In order to gauge which API endpoints are utilised more than others, it is necessary to capture API usage data, including patterns, responsiveness and performance. It is important to choose an appropriate API monitoring method that does not negatively influence API performance beyond a threshold that you deem acceptable.
5
Layered Security Controls
In alignment with a larger overarching DevSecOps capability, it is important to plan layered security controls across your development cycles. These should include API threat modeling, security testing, prevention, detection, response and improvement.
6
Security
Testing
API security testing, which is linked to the reliability of the API, should be planned in alignment with meeting your consumer needs.
​
The inherent advantage of a loosely coupled, isolated and cohesive API is the ease of performing testing, including security testing, on the API; compared to the increased difficulty of comprehensively testing the web application that the API likely supports.
To propagate a tailored security outlook for each API set, it is important for your developers to test APIs as products, as opposed to isolated projects. If your security testing does not take into account the unique product context, and only tests each API set separately, it is likely that some vulnerabilities will not be identified. This is a result of generic security testing, as opposed to tailored testing underpinned by an understanding of the product's business logic.
7
API Documentation
In many commercial environments, particularly for technology organisations with aggressive growth plans, poor visibility of APIs can result in serious security challenges. In order to minimise long-term cyber risk posed by shadow APIs, we recommend you register all your APIs to your API management platform or populate them in an API catalogue.
To drive adoption of your APIs by your developers as well as your wider community of practice, your strategy should mandate a structure for documenting APIs. This structure should be enforced across all your development teams. By enforcing this, your APIs will become easier to maintain and your developers will be provided with the necessary foundations to use the APIs productively.
Closing Thoughts
​By defining an effective API security strategy with the direction provided in this article, you will be well-positioned to design, implement and manage your APIs in a manner that minimises long-term cyber risk.