Security paradigms do not change on a yearly basis — look at OWASP, they released their top 10 API vulnerabilities list only twice since 2019, and problems with authorization remain the top concern. However, the environment around us and technologies do change quite rapidly, and the start of a new year is always a good point to have a closer look at the trends. At Curity we always try to keep our eyes open on the API and identity space to understand how things will  evolve in the near and more distant future.

Below I describe the topics that I believe will be relevant for API developers and architects in the coming year, especially when thinking about API security.

AI Meets API

It’s definitely no surprise that AI will be an important topic in 2025. The trend that especially affects API security is the rise of AI agents — these are pieces of software capable of using other tools and APIs to perform tasks and which the user operates using natural language commands. For example, you can ask an AI agent (using voice commands or by typing sentences) to book a flight and hotel for your next trip. The agent must then somehow integrate with a system that will eventually fulfill the task — if it finds a suitable API, then it will use it. This means that you need to think about your API not only from an integrator’s developers’ perspective but also from AI agents’ perspective. Think how an agent will be able to find the API, understand how to use it, register, sort out billing, receive proper permissions, etc. It’s important that you know and control how agents will use your products. Remember that even if you decide not to open up an API, some agents will be able to integrate with your products using the same interface your users utilize. You might then have less control over how the agent integrates.

APIs and AI Gateways

The abundance of AI agents and LLMs have resulted in the emergence of a new type of product on the market — AI gateways. They have similar functionality to API gateways, but are tailored for some AI-specific features. For example, they are able to route traffic to concrete LLMs and can implement centralized security features, like protections against prompt injection. You should have a look at these if you’re working with AI integrations.

Auditable Authorization

Authorization is not a trivial matter, and companies continue to search for better approaches to properly implement it. Especially in large organizations with many APIs, it’s important to ensure that authorization rules are manageable and auditable. That’s why we see a growing trend of externalizing authorization to dedicated systems. In the coming year we will see organizations use more solutions like Open Policy Agent, OpenFGA, or Cedar, as API developers focus on trying to tame the top API vulnerability — broken authorization.

Using OPA to implement manageable and auditable authorization

Passwordless Authentication

If you’re not yet familiar with passkeys, now is the time to catch up. This cryptography-based technology will eventually replace passwords by offering better security and better usability than the classic authentication method. Major browsers and operating systems are constantly improving their support for passkeys, and this year the support is good enough to safely migrate your users to the new solution. Many websites already allow you to use them for passwordless logins, with some big-player examples being Gmail, Paypal, and GitHub.

Even though it’s not a technology that you will use directly in APIs, improving the security of your users’ authentication improves the security of your APIs and data — it’s harder to steal data through your APIs. Especially because passkeys come with an important security improvement — they are phishing-resistant by design because every passkey is tied to a specific domain name.

Verifiable Credentials

In 2024 there was a bit less buzz around verifiable credentials, but this does not mean that they are less relevant. On the contrary, the standards are becoming more mature, and more and more countries are closer to rolling out nationwide wallets, or at least finalizing regulations (like the EU’s eIDAS). VCs will not become widely available in 2025, but they are coming, and companies should be prepared. As Jacob Ideskog explained in this Nordic APIs Platform Summit keynote talk, their introduction will impact APIs as well. As users will have more control over their data and what they share with other parties, APIs will have to ensure that they are ready for potentially limited user information.

Zero-Trust Security in Cloud Native Environments

In a microservice and cloud environment, it is important to understand that perimeter security is no longer sufficient. When you work with distributed systems, you want to ensure that every service and every instance is able to strongly authenticate and authorize the callers—the user or software that initiated the request, the other service in your system that is calling this service, or the machine instance that is calling this machine instance. This is the work that the IETF’s working group Workload Identities in Multi System Environments (WIMSE) is trying to wrap its head around. Watch their space this year as they will be publishing their first best practice documents that will facilitate secure implementations of zero-trust solutions that consider both application-level security (access tokens) and infrastructure-level security (mTLS and SPIFFE).

A big part of WIMSE work is dealing with “workload identities”, that is, identities of applications and instances. Managing these identities is an important part of your system’s security. This year OWASP released a new list from their top 10 series that tackles specifically the risks associated with, what they call, “non-human identities”.

Sender-Constrained Tokens

The vast majority of APIs are secured with bearer tokens. When an API receives such a token, it only checks whether the token itself is valid, and whether the requested action is allowed. The API does not check whether the sender was allowed to actually use that token, because it has no means of verifying that. This means that when someone manages to intercept an access token, they can call your APIs and steal data, and you might not even notice the theft because they will be using legitimate tokens. With sender-constrained tokens, you tie the token to the application that initially received the access token. There are now standards and solutions that allow the use of sender-constrained tokens on almost any device. For example, you can resort to things like Dynamic Client Registration (DCR) and Demonstrating Proof of Possession (DPoP) to change bearer tokens into sender-constrained tokens in mobile apps. I think that in 2025 more APIs should require its integrators to use sender-constrained tokens to better protect their users’ data.

A malicious client cannot reuse a stolen sender-constrained token

Evolving the API Spec

We’ve lived with the OpenAPI spec for a long time now, and most people in the API space are familiar with it and most probably use it. Its maturity does not mean stagnation, and I don’t mean just new versions of the spec itself. There are new tools emerging that enhance working with API specifications. Two notable examples that you will hear more about in the coming year are Typespec and Arazzo. Typespec introduces a new, code-like, typescript-like way of writing the API specification, which is then transpiled into a standard OpenAPI YAML. Arazzo allows using YAML in a standardized way to define API workflows, something that, until now, has been  missing from the OpenAPI spec.

An interesting new approach that is emerging in the space of specifications is the Common Architecture Language Model, which tries to standardize architecture as code.

The Great Unbundling and Cloud Repatriation

I heard the term “the great unbundling” quite a few times last year, and I think the trend will continue. It means that companies will continue using smaller API tools that are tailored for concrete jobs rather than using large platforms that offer every solution possible. This trend allows companies to find solutions with more specific features. It also allows them to more easily switch vendors as they don’t need to swap every feature at once. Smaller vendors also tend to react more swiftly to new trends and needs, thus offering new features more quickly. In the API security space, this will allow companies to more easily integrate with new, innovative products that provide better security solutions.

Another trend I noticed emerging last year is cloud repatriation — companies now tend to go back to private, self-hosted clouds and infrastructure, because costs of using public clouds often spiraled out of control. Leaving public clouds means also regaining control of the physical location of data, which became important with the advent of regulations like GDPR and CCPA. This does not directly affect API security, but abandoning public clouds can require changes to infrastructure-level security.

Look Beyond AI

Going into 2025 we should look beyond AI. It’s definitely all over the place now, but it’s far from being the only, or the most important thing, happening in the API security space. 2025 will be an interesting year for APIs, and I think we will see many technologies both emerge and mature as the year progresses. API security will be as relevant as ever, and I hope that we will finish the year with more secure APIs. Maybe the next OWASP top 10 list will have to look for a new vulnerability to crown.