This week, we have a pair of doubleheaders — firstly, The New Stack on six API trends for 2024 and how API keys are leading to vulnerabilities, and then Kin Lane (aka. APIEvangelist) on the future of API gateways and why API discovery is hard. We also have an article on threat modeling for API gateways and news of 42Crunch at the API Summit in Austin.
Article: Six API trends for 2024
The first article this week comes from The New Stack on their trends for APIs in 2024. API adoption and evolution continue to be a hot topic, and this article identifies some really interesting trends as the industry evolves, including, as expected, API security.
Here are the six trends:
- APIs from multiple sources: APIs have become a vital cog in the software supply chain, allowing connectivity between upstream providers and downstream consumers. Unfortunately, this provides an increased attack surface, as identified in the new OWASP API Security Top 10 API10:2023 Unsafe Consumption of APIs.
- Multiple API standards and formats: While REST is the dominant standard for APIs, newer protocols such as GraphQL and AsyncAPI tend to complicate the landscape further, mainly for security.
- Unbundling API technology: Organizations have begun to find that their bundled solutions (such as APIMs and gateways) lack critical capabilities and have begun to unbundle in favor of more niche and bespoke solutions.
- API technology sprawl: API technology is rapidly evolving (think Kubernetes and FaaS), which poses challenges for governance and security.
- API gateway evolution: The role of the traditional API gateway has changed, and nowadays, organizations are embedding lightweight gateways closer to their APIs.
- Advanced API security: API security can no longer be handled solely at the gateway level, and organizations are faced with an array of security solutions, from shift-left developer-focused tools to the latest in machine learning solutions claiming to detect emerging threats.
This is a very interesting read — for me, the comments on the evolution of the API gateways ring true, as do the observations on the API security landscape.
Article: API keys leading to vulnerabilities
The next article is again from The New Stack and discusses how API keys leave your APIs vulnerable to attack. The article suggests that despite the adoption of API gateways, APIs are still hamstrung by their reliance on API keys as the sole method of protection.
The first and most obvious problem with API keys is that they are frequently very long-lived, often with no expiration. The recent spate of leaked API keys presents a real risk to APIs protected only by keys. Remediation usually necessitates a revocation of keys and the generation of new keys, including the reconfiguration of clients.
The main issue with keys, according to the authors, is that keys do not offer fine-grained access control — if you have access to a key, you have access to everything in the API. They recommend using tokens (which contain embedded metadata, such as claims) to limit the token’s scope to specific subsections of the API or its data and the allowed operations. Tokens are usually issued using robust protocols such as OAuth2, adding greater resilience to their distribution and use.
So why doesn’t everyone use tokens, always? The fundamental reason is that they require significant investment in the design and development phase. When pushed with time pressure to deliver, many API teams will opt for a simple key-based solution rather than using a more robust token-based approach.
The article concludes with a case study of how the Curity identity server helps simplify the adoption of tokens. I particularly recommend Curity’s API Security Model for API architects and system designers — hopefully, we are all rapidly moving to Level 3.
Article: The future of API gateways
On the topic of API gateways, we have a really great read from Kin Lane (aka. APIEvangelist) on the future of API gateways and where he sees the future taking us. As one would expect, given Kin’s pedigree in the API space, it is an exhaustive look at the history of API gateways, the current market and players, and predictions.
While the article is worth reading in its entirety, his view on the core capabilities is spot on, namely:
- Security: The majority of organizations are highly reliant on their API gateways for the security of their APIs, and increasingly, new players are leading with new security features. Kin suggests that security features will need to be standardized and hardened.
- Traffic: Traffic management is the other key role of the gateway, allowing organizations to manage access to their APIs and to allow them to scale gracefully.
- Mediation: As the access point to the organization’s data, gateways are pivotal in managing who has access to what data.
- Transformation: As the API protocol and payload landscape continues to expand, the gateways become more important in transforming data from one domain to the other in an efficient and scalable manner.
- Virtualization: As the move to design-first accelerates, the API gateway will likely take on a greater role in providing mocking or virtualization capabilities.
If you’re involved in selecting or buying an API gateway, the article has a great list of criteria and differentiators. Finally, in Kin’s own words:
“the API gateway of the future has to exist with a small federated footprint that is programmable and extensible. This gateway has to meet the needs of the product and engineering teams who depend on them, and like APIs, respond and evolve with whatever is happening next”
Article: Why API discovery is hard
The second article from Kin features his thoughts on why the perennial topic of API discovery is harder than one would necessarily expect. The lack of a known inventory is a top challenge for API security teams — you cannot secure what you do not know about.
Kin provides much context on the various dimensions of API discovery, including how to govern the API landscape. Along with security, having a known inventory is essential for adequate governance of APIs in a modern organization. This includes touch points such as:
- Policies: defining what policies already exist.
- Regulation: understanding the requirements of regulations such as GDPR.
- Compliance: ensuring that APIs are compliant.
Thanks to Kin for two great contributions to the newsletter.
Article: Threat modeling of API gateways
API gateways are the focus of our last article, this time in the form of a practical guide on how to threat-model an API gateway. As mentioned in previous articles in this newsletter, the API gateway is often the bastion of security for APIs and, as such, should be thoroughly threat-modeled to ensure there are no avoidable weaknesses.
From a security perspective, the API gateway provides the following functions:
- Authorization and authentication
- Routing
- Offloading
- Transport Layer Security (TLS) termination
- Aggregation
- Single point of access
The authors identify several common API security challenges and best practices as follows:
- Inadequate rate limiting: APIs can easily be abused using brute force attack methods to deny access to the API or bypass login or password reset controls.
- Insufficient data validation: APIs may be vulnerable to data injection attacks or disclose excessive data. Both of these can be prevented at the gateway level by packet inspection.
- Insecure direct object references (BOLA): Gateways can be used to partially mitigate against the threats of BOLA by using pseudo identifiers.
- Lack of logging and monitoring: Gateways are an excellent enforcement point for central logging and monitoring all API traffic. Most offer excellent integrations with common logging and monitoring platforms.
- Lack of encryption: API gateways are an ideal point for enforcing TLS on all inbound connections.
- Inadequate authentication and authorization: API gateways can perform authentication and authorization of inbound requests before they access internal APIs, ensuring the uniform enforcement of access control.
- Misconfigured cross-origin resource sharing (CORS): APIs are able to enforce cross-origin resource sharing (CORS) at the gateway level, reducing the burden on individual APIs to implement this correctly.
- Exposed sensitive data: As per the previous comment about data, gateways can protect against the leakage of sensitive data via an API response.
- Lack of API versioning: Gateways can enforce versioning by routing APIs via path fragments and routing strategies.
It is worth bookmarking this guide if you are involved in implementing API gateways.
Event: 42Crunch at API Summit in Austin
The Austin API Summit 2024 is approaching fast! Don’t miss your chance to join us on March 12-13th in Austin, TX – to meet industry colleagues, get inspired, and gather knowledge about the technology, trends and best practices shaping today’s API economy.
If you haven’t yet booked your Early Bird ticket, register by January 19th to get the best price!
The event includes a fantastic lineup of speakers who will discuss many different aspects and best practices of API design, security, documentation, management, and more.
Also, Early Bird registrants will be the first to be offered discounted hotel rates available for the Austin API Summit delegates. So don’t wait to take advantage of the best price!
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
