Digital transformation and IT modernization has built upon, to a great extent, the flexibility of developer-friendly API architecture. As the connected enterprise has scaled, so too has the machine-to-machine communications that APIs facilitate. However, the ubiquity and openness of APIs make them attractive targets for hackers. API protections do exist, but their effectiveness is limited, and successful defense tends to involve a significant investment of resources. A new approach, based on obfuscation of the API itself, shows promise in mitigating some of the worst API threats.
The promise and impact of APIs
With their ability to connect virtually any application to any data source, regardless of platform or programming language, APIs have let loose a lucrative torrent of innovation, particularly in the mobile space. APIs impact on the Internet and the digital enterprise has been immense. According to research from Akamai, about 83% of internet traffic is API-based. Nearly all mobile apps pull data from public APIs connected to data sources, and the standards-based nature of APIs makes this a highly efficient architecture to build and operate. Their success had led to a boom in corporate partnerships and data mash-ups, such as banking apps that share insurance policy data.
Understanding API risk
The very openness of APIs causes security problems. An API is, after all, literally a portal for extracting what can be incredibly sensitive data. Beyond requiring a specific syntax, they often have little to no native security. As a result, API architecture creates a massive attack surface. Malicious actors can exploit these access points by writing automated scripts that steal data at scale.
API users, a group that includes pretty much every enterprise with mobile connectivity, are experiencing an epidemic of API hacking, abuse, disruption. Industry research reveals that 95% of organizations experienced an API security incident in the last 12 months. Salt Security found that API attacks increased over 600% from 2021 to 2022. Meanwhile, Gartner predicts that 90% of web-enabled applications will expose broader attack surfaces because of APIs. Dealing with these risks is not cheap, with a new study from Imperva estimating that vulnerable APIs cost organizations between $40 and $70 billion annually.
API security risks range from configuration errors and unpatched APIs to a lack of API controls, such as for “throttling” excessive API calls. In some cases, unauthorized “shadow” APIs or abandoned earlier versions of an API create unseen portals for malicious actors into data rich targets.
The worst threats are those that reverse engineer, mimic, and attack APIs with programmatic scripts. One example is credential stuffing attacks, a process that involves testing thousands of stolen authentication credentials to see if any grant access. For example, an 18-year-old recently perpetrated a credential stuffing attack on an API at the DraftKings betting site that gained him access and control over more than 60,000 user accounts. He then sold this account access to other criminals, who proceeded to approximately $300,000 from the company. The DraftKings API hack was not an isolated incident; account takeovers are as common as they are pernicious. The financial impact of attacks like this is significant. The FBI estimates that the credential stuffing attack costs enterprises an average of $6 million per year using current security methods.
Current modes of API security
In their native state, APIs are utterly defenseless. They are designed to respond to any entity that formulates a correct API call. This is fine if the API is providing public weather reports or stock market information. For any sensitive or regulated data, it’s a huge security headache.
A number of technologies and practices have emerged to protect APIs and the data they represent. Some involve linking APIs with identity and access management (IAM) solutions. With IAM integration, which may include the generation of unique user tokens, such as OAuth, only verified users can access the API, at least in theory.
Other API security countermeasures include web application firewalls (WAFs) and bot detection. WAFs can analyze HTTP traffic going to an API and block suspicious IP addresses and geographies. They can enforce rate limiting policies, which protect against distributed denial of service (DDoS) attacks as well as the kind of repetitive requests seen in BOLA and credential stuffing attacks. With regard to DDoS, bot detection tools can identify and block API calls from entities they suspect to be non-human, perhaps using machine learning (ML) to hone their analytical capabilities. They can also enforce policies based on “confidence scores” that measure the characteristics of API requests.
Purpose-built API security tools, such as API gateways and API management consoles, add many further capabilities. They might conduct regular inventories of APIs, highlighting forgotten or “rogue” APIs. They can monitor API traffic, carefully screening for all sorts of scripting exploits and other anomalies that suggest a threat. Others automatically analyze API configurations and flag those that need remediation.
Challenges and deficiencies of existing approaches to API security
API security solutions can be effective, up to a point, but they are limited by a number of significant challenges and deficiencies. For one thing, they are all invariably resource intensive. Committing to a WAF, for example, means more than just buying a WAF. It requires dedicated staff and continuous tuning. Because hackers continuously retool to circumvent existing defenses, security teams often get caught up in a resource-intensive cat-and-mouse game. This applies for almost any current API security solution, such as a bot detection tool or an API gateway.
Another issue with most API security tools is intensity settings. Too lax settings permit hacker activity, but too restrictive policies result in false positives, and real users are treated as fraudsters. Unfortunately, there is no “Mama Bear” setting – there always seems to be an ambiguous segment of traffic in which the fraudsters look authentic and the real users might be fake.
While dealing with fraud is administratively burdensome, blocking authentic users tagged as scammers also drives overhead. Customer frustration can cause financial losses, along with costly support desk calls, and so forth.
Seeing accessibility as the root of the problem… and the start of a solution
The biggest difficulty with existing countermeasures is the most basic: external-facing APIs that are publicly discoverable and accessible. This forces defensive solutions to perform damage control reactively. If correctly formatted forged calls get through, the API will respond, without any guardrails, regardless of the source of the call. These basic aspects of API architecture put the API defender at a serious, unending disadvantage.
Could it be different? What if external APIs did not need to be so publicly exposed? Yes, it is possible to take a new approach that’s similar to that of private APIs. A mobile app could have software credentials that allow access to an API via a private connection. In this model, the API endpoint becomes as undiscoverable to the general public as if it were offline. The API would thus remain inaccessible to unauthorized third parties, shutting down most bot traffic. Obfuscation protects the API traffic itself, which further impedes reverse engineering.
API security problems do not magically vanish when there is such API obfuscation, but the level of risk drops dramatically. For instance, it’s far harder for an attacker to reverse engineer an API call to exploit a broken object level authorization (BOLA) vulnerability if he can’t find the API in the first place. An attacker can’t stuff a million credentials into an API he can’t see, and so on. The API connection protocol requires no inbound calls, so security teams can close ingress ports.
Conclusion
It is possible to enjoy the scalable benefits of external API architecture without having to deal with the associated security headaches, and the shortcomings of existing API threat mitigation methods. Obfuscating public APIs can go a long way to making them more secure, and with relatively minor integration effort and administrative overhead. Given the potential to avoid disruption, customer frustration, and millions of dollars of overhead, the effort is surely worth it.
