API security challenges

The Active API Armour has been designed to address some of the most pressing challenges faced today by developers and security teams. We propose a novel approach that significantly strengthens the security of your systems, helps you to avoid errors in the implementation of API security, and makes your work much easier, eliminating repetitive, burdensome tasks and costs.

The landscape of API threats is ever-evolving and adversaries are mercilessly exploiting all the potential attack options. Some of the most common and emerging gaps that have been highlighted by the community include:

Theft and misuse of bearer tokens

The two standards most used by developers and identity service providers for authentication of API consumers and authorization of their access, are custom-developed JSON Web Tokens and OAuth tokens. Both approaches use the principle of bearer authentication, meaning that whoever has the token, is authenticated as a seemingly legitimate user. When not handled with absolute security, these tokens are exploited through theft and misuse, leading to access to sensitive data by adversaries. According to the available data, about 80% of successful attacks on APIs come from seemingly legitimate users.

Moreover, bearer-based authentication mechanisms do not allow producers to distinguish between actual legitimate and seemingly legitimate users. This causes many attacks to go undetected for days and even months.

Complex configuration of authorizations

All bearer tokens require development teams to very carefully manage the scope of consumer permissions, as well as the expiration windows, to prevent any possibility of misuse. In practice, tokens with misconfigured permissions, as well as old tokens, are very often used by attackers to gain access to sensitive data.

Secure storage and management of secrets

The API infrastructure, as well as the secrecy of data being transmitted, is based on a growing number of secrets that teams need to manage. API keys, API tokens, TLS certificates, private keys in Public Key Infrastructure, as well as shared symmetric encryption keys, are all essential to the security of

APIs. All these secrets often move across code repositories, continuous integration and continuous delivery (CICD) systems, test infrastructure, deployment applications and data lakes, logging tools, or even team collaboration apps like Slack.

Best practices recommend the use of secure vaults and key managers to, at least partially, automate the process. Nonetheless, teams still face a significant cost and burden of the management of these secrets and very often spend hours every week on their provisioning, distribution, rotation, revocation, monitoring, and control.

Limitations of TLS/SSL

Adding encryption to API workflows typically requires custom development and in most cases is limited to the use of TLS/SSL protocols.

This approach increases the security of data in transit, but presents multiple well-known flaws such as supporting legacy cryptography methods, adding large RSA signatures that authenticate only one side of the communication, and vulnerability to network eavesdropping through proxies and communication channel break-ins.

One possible solution to these challenges is the establishment of end-to-end encryption, where only communicating users can participate in the exchange of data. This requires users to be able to exchange cryptographic keys – leading back to the issue of secure key management.

Emerging quantum computing threats

Today’s API platforms are using classical public key cryptography, such as RSA, Elliptic Curve signatures, and Diffie-Hellman key exchange, to establish secure end-to-end encrypted connections between devices. All these algorithms are based on difficult mathematical problems that have long been considered too computationally intensive for computers to solve.

The rise of quantum computing threatens to change this status quo. A sufficiently powerful quantum computer could solve these classical mathematical problems in fundamentally different ways, and therefore — in theory — do so fast enough to threaten the security of end-to-end encrypted communications.

Although quantum computers with these capabilities do not exist yet, extremely well-resourced attackers can already prepare for their possible arrival. The premise is simple: such attackers can collect large amounts of today’s encrypted data and retain it until they acquire a quantum computer that can decrypt it in the future, an attack scenario known as Harvest Now, Decrypt Later.