There’s a big problem with the bearer model. Let's explore where, why, and how the bearer model falls short when it comes to defending APIs from modern threats.
Even if security teams maintain strong secrets management hygiene, it’s difficult to account for when these credentials might leak. That means leaks can sometimes go undetected, opening organizations up to attack. Once a threat actor has any of those credentials, from tokens to certificates to API secrets, it’s game over.
Take what happened to GitHub, for instance. In 2022, malicious actors breached dozens of enterprises through the tech titan by using stolen OAuth tokens issued through Heroku and Travis CI. While GitHub quickly revoked these tokens, the damage had already been done: The attackers were able to download a treasure trove worth of private repository data from countless users – and even large-scale enterprises – connected to the platform.
Infosecurity Magazine reports that detected API attacks in 2022 surged by 3.5 times year-on-year for the financial services sector alone. Meanwhile, Gartner states that API security standards have remained relatively unchanged.
Here’s what we can learn from GitHub and these other attacks: It’s time for organizations to adapt proactive, not reactive, API security practices. That means moving above and beyond the bearer model to more efficiently secure an organization’s most highly targeted and vulnerable resource: Its APIs.
What is an API Gateway?
An API gateway acts as a proxy between back-end data and front-end client services. It’s essentially the link between information and data consumers, routing requests and calls to the right microservices collecting and aggregating data before sharing it with clients. API gateways sit in front of your organization’s APIs, acting as single entry point between:
Even with threat actors ramping up their efforts, many security teams are beholden to this tradition to keep APIs safe: Using the bearer model.
The bearer model is an HTTP authentication scheme that helps validate identity. How does it do this? By using security credentials – sometimes called “bearer tokens” – that act as a proof of identity.
These credentials are used to grant users access to API gateways and their services. They can come in the form of secrets, keys, and tokens with two different functions — validating ID and granting access.
API credentials work by:
Think of secrets, keys, and tokens as passwords — or a digital set of house keys. They’re what allow users access to data through API gateways. No house keys, no entry – no credentials, no access. Machines using an API must “bear” the right credentials with them to successfully make calls and pull data.
Here’s the major flaw with API secrets and the bearer model: When threat actors gain access to tokens, they can move faster than security teams can respond. According to Cisco, over 29 billion devices will be connected to the internet by 2023. More traffic means more certificates to validate identities and access – inundating teams with countless sets of credentials to track, monitor, and periodically rotate.
Because of the sheer amount of unique credentials that today’s companies must manage, it’s easy for leaks to fall by the wayside. That means stolen or compromised tokens can go undetected for weeks – and in the case of Toyota’s breach, sometimes even years.
The disparity between fast-acting threat actors and slow security response can create the perfect storm for a devastating API leak.
The bearer model is not enough to consistently validate machine and user identity. Tokens, keys, certificates, and secrets are static methods to authorize access and can easily be intercepted or stolen. The only thing these credentials validate is that whoever (or whatever) is “bearing” it has the right token — not that the bearer themselves is an authorized user.
Remember the analogy of digital house keys. What’s the problem with just using a set of keys? They don’t really validate that you’re the homeowner. They just grant access to a home. Should those keys fall into the wrong hands, that person could easily walk into your living room, kitchen, bedroom, etc. – even if they categorically shouldn’t be there.
While tokens can verify users session-to-session as they make API calls, they cannot ensure that the user using the login credentials is the correct user in the first place. Most of all, the bearer model falls short in protecting organizations from one of the most devastating kinds of attacks: Third-party breaches.
Even the most pristine bearer model hygiene is not enough to keep your organization secure, as it only ensures your internal API security health. Even if your security teams prop up decent bearer model hygiene, their efforts cannot account for (possibly lax) security practices of third-party collaborators or partners.
Remember that 2022 GitHub incident we mentioned earlier? That’s the perfect example of a compromise caused by leaked third-party access tokens. The threat actor actually hacked Heroku and Travis CI, third-party platforms connected to GitHub, and used stolen AWS access keys from those apps to breach private NPM repos on GitHub.
Those stolen access keys allowed the attacker to swiftly gain authorized access to the entire registry’s infrastructure. At the end of the day, that OAuth token theft compromised over 100,000 users and their sensitive data.
The bearer model’s weaknesses in securing API gateways can lead to big trouble – especially with the rise of machine-to-machine communications. Today, an overwhelming majority of internet traffic is facilitated by machines. That should come as no surprise, with Gartner sharing that machine intelligence consistently outperforms human intelligence in speed, consistency, and scale.
Machine-to-machine communications make sharing information quicker than ever. But that means threat actors can share, download, and plunder data just as quickly as you can. That magnifies the risks already posed by the bearer model.
To keep up with the rise of M2M communications, organizations cannot solely rely on the bearer model as their last line of defense. They need other security measures in place to help automate machine trust.
Here’s the new cybersecurity status quo: Prepare for when — not if — leaks happen. At their best, these leaks are embarrassing. At their worst, they go under the radar for months, even years, and cause mountains of financial and reputational damage.
To keep up with the rise of M2M communications, organizations cannot solely rely on the bearer model as their last line of defense. They need other security measures in place to help automate machine trust.