On May 26, 1995, Bill Gates wrote his now famous memo, “Internet Tidal Wave” to Microsoft executives and all his direct employees. In the memo, he admitted that he had changed his stance on the Internet’s benefits and now considered it to be the company’s highest priority. In August of that year, Microsoft released the first version of Internet Explorer with an add-on package (“Plus!”) for Windows 95. The rest, as they say, is history.

Another famous memo by Bill Gates came after he spent a weekend reading the book Writing Secure Code. The then-477 page manuscript by Michael Howard and David LeBlanc, senior security engineers at Microsoft, warned about the dangers of cybersecurity problems caused by poor coding hygiene. On January 15, 2022, Bill Gates sent out a memo titled “Trustworthy Computing”. He directed that Microsoft should prioritize security over adding new software features. “Eventually,” Gates wrote, “our software should be so fundamentally secure that customers never even worry about it.”

Today, some 20 years later, the book has grown dramatically and is as relevant as ever. Cybersecurity issues remain front and center. They’ve made their way into the public consciousness with reports of ransomware attacks disrupting critical infrastructures like transportation, energy, and healthcare. Supply chain attacks undermine trust across the industry and a significant increase in cybersecurity incidents impact remote workers and disrupt their daily life.

We must constantly stay vigilant and look at the problem holistically, both with the shift-left approach and incorporating security earlier in the development process (Bill drew the right conclusion here), and by recognizing that we’ve increased the attack surface by creating more integrated systems that connect to APIs. While application front ends are often the focus of security controls and testing, connecting APIs can be the most vulnerable components and are rarely adequately monitored and equipped with automated controls to detect and respond to threats.

APIs are much more important today than in the past. Their role has changed in four key ways:

• Sensitivity: APIs have been around for a long time. First, in single monolithic applications that allow user applications to use the underlying operating system’s services. Then came remote APIs, which until a few years ago were mainly used for low-level system changes, configurations, and settings. However, now they’re used for any kind of control or data exchange. This can be anything from controlling the speed of a nuclear centrifuge or reactor, to transferring millions of dollars, or accessing all your sensitive personal data.
• Expansion: Additionally, modern enterprise can easily have tens of thousands of APIs in its cloud environment (maybe even two or three different clouds). The proliferation of distributed cloud native applications is leading to even more API-based connections. Likely, each of these applications will use multiple API gateways and it’s nearly impossible to fully understand how APIs are routed and invoked across the network, and if they pose a risk to the enterprise.
• Hidden vulnerabilities: To understand the full attack surface your APIs provide, you need to understand what “good” or “normal” looks like, the API’s expected behavior, and then determine what’s wrong. This is really difficult for current security tools as they lack the full context of how your APIs work.
• Simple exploitation: Hacking an endpoint or mobile device running a banking application and manipulating it to perform fraudulent monetary transactions requires years of experience in cybersecurity, reversing, hacking, and bug exploitation techniques. Exploiting an API vulnerability created by a lack of authentication to use the same primitive methods only requires basic HTTP knowledge and a terminal or Postman application.

These are all reasons why APIs are currently one of the most attractive attack vendors. The sheer size of the attack surface gives attackers plenty of opportunities to immediately exploit.

Traditional web applications can be relatively easily protected with inline security devices like web application firewalls, gateways, and proxies. Attacks using methods like SQL injection, or cross-site scripting would be relatively easy. The amount of traffic generated by traditional web services compared to API-based systems can also vary. Malicious or incorrect API requests are diluted by a much larger volume of calls generated by well-functioning automated systems. Trying to control this kind of traffic with static validation checks is nearly impossible. API calls are growing twice as fast as HTML traffic is. With modern API-based applications, we have to deal with much more sophisticated attacks that try to abuse the underlying business logic exposed by the API.

An example of this was the recently disclosed vulnerability in the trading interface for the cryptocurrency exchange Coinbase. It allowed users to submit trades to a specific order book using a mismatched source account. For example:

• A user has an account with 100 SHIB and a second account with 0 BTC.
• The user sends a market order to the BTC-USD order book to sell 100 BTC, but manually changes their API request to specify their SHIB account as the source of funds.
• In this instance, the validation service would verify that the originating account has sufficient funds to complete the trade, but not if the originating account matches the proposed asset for trade submission.
• Therefore, a market order to sell 100 BTC would be entered into the BTC-USD order book on the Coinbase exchange, making the proceeds effectively free.

The underlying cause of this error was a lack of logic validation in a retail brokerage API endpoint. The OWASP API Security Top 10 lists this as number 1 as an example Broken Object Level Authorization. So the question is, who is ultimately responsible for securing APIs?

We need to look at API security holistically, from design to development, and from deployment to operation. All of these steps require understanding and implementing appropriate security controls. Starting with design and development, companies are under constant pressure to outperform their competitors. In digitally driven businesses, that pressure will inevitably transfer to developers who need to get new and improved apps to market faster. Traditionally, security has been on the opposite side of speed. It’s perceived as an obstacle by app developers who want to help companies capitalize on market opportunities.

Software inevitably has bugs, but not all bugs cause security problems

I recently participated in a web session by Ken Duda, CTO & SVP of Software Engineering at Arista Networks, about Arista’s Software Quality Journey. During the discussion, he referenced several studies by Jim Gray (Tandem) about software quality and bugs. He presented a study that showed engineers who first check their code and tell their manager it’s ready typically will have one error per 10 lines of code. When they run the code through quality assurance and it’s approved, the error rate typically drops to one error per 100 lines of code. Once the code finally goes into production and goes through several maintenance releases over a few years, the error rate drops to one error per 1000 lines of code. In this traditional “waterfall” software development method, developers are solely responsible for creating new functions. Problems that occur during development are only identified in further testing phases, where fixing them is costly. Figure 1 shows this trend.

Fig. 1: Troubleshooting cost in production phases

So, the idea is to fix all API security issues before they go into production and prevent the few bugs from growing into serious security breaches. Not only that, but it should be much faster than the traditional methods. This includes making the security validation process part of the development process by moving validating processes into CI/CD pipelines.

Let’s put aside the discussion about the pros and cons of an API-first versus a code-first approach and turn directly to the API’s specification and documentation. This might be with a specification language like OpenAPI. If you compare the API’s actual usage by examining network traffic with the AP’sI documentation, you’ll often find gaps in the API functionality’s understanding or a lack of updated specifications. To fully understand the attack surface of your API’s, we need to consider four key elements:

• Traffic: What information and data types are actually sent and received, and how much, how often, etc.? This gives you a better understanding of what “normal” or “good” looks like.
• Code: What is the API capable of? What does it allow? What primitive function can a successful request to this API have? This will help you better understand potential vulnerabilities and exploits.
• Infrastructure: What does the network and environment look like, including how information is routed, and what controls/policies are in place? This helps identify potential vulnerabilities, like misconfigurations.
• Documentation: What does the organization understand about an API’s capabilities compared to what it actually does? This is how to identify blind spots and vulnerabilities they can cause.

The only constant in IT is change

The explosive growth in API usage can be explained to some extent by the ongoing digital transformations. APIs are essential in this transformation since nearly every process improvement idea involves linking previously separate software applications and data sources. For a store kiosk to communicate with the mobile app, which can then communicate with the website, the e-commerce backend, and the interactive voice response (IVR) system, there must be an API at every connection point.

In healthcare, the patient team’s mobile app uses APIs to connect to internal communication platforms and electronic health records (EHR). Government mobile apps need APIs to access data from public data stores and workflow processes from legacy government systems.

APIs also play a role in financial services. A bank can continue its digital transformation by allowing customers to access their life insurance policies using a banking app, for instance. In order for this to work, an API call needs to be built into the banking app that can reach the insurance company’s systems. The business processes included in the new banking app call functions in the bank’s mainframe-based legacy system with an API.

When we talk about APIs today, we need to consider many different standards. Currently, the industry has settled on RESTful APIs, while newer standards like GraphQL and gRPC are seeing a resurgence. This brings another interesting challenge from a security perspective. Consider how REST APIs work compared to GraphQL: With REST, we typically have a separate endpoint for a given functionality. But with GraphQL, there’s usually an endpoint that dynamically responds to a query. There isn’t much hope of applying rule-based security validation to this kind of dynamic environment.

What does an API look like from a security perspective?

From a security control perspective, an API is a combination of:

• Method: GET, POST, PUT, …
• Hostname: devm.io
• Path: /v2/users/all

For example, when we perform GET on devm.io/v2/users/all, it’s different from DELETE on devm.io/v2/users/all. The method in this example tells us about potential security implications of the performed operation. Security validation can use this context to decide if it’s a valid, expected request or a malicious attempt.

As a second example, let’s compare POST on testing.devm.io/v2/user/admin with POST on devm.io/v2/user/admin. In this example, the hostname gives us additional security context that affects our approach to validating the request.

To fully understand the security posture of your APIs, we need a comprehensive, holistic view of your landscape, including an inventory of all APIs: those running through an API gateway and those not running through an API gateway; internal APIs versus external and partner APIs, etc. We also need to map the data going to and from the APIs and classify the data going through the APIs. We need to understand who is calling the API, what data he/she is sending/receiving, and where the call is coming from.

To fully understand your API’s security posture, we need a comprehensive, holistic view of your landscape. This should be an inventory of all APIs, including those running through an API gateway, those not running through an API gateway; internal APIs versus external and partner APIs, etc. We also need to map data going to and from the APIs and classify data going through the APIs. We must understand who is calling the API, what data they are sending/receiving, and where the call is coming from.

So how widespread is this problem?

KnightInk Research conducted an independent study which tested 55 mobile banking apps. The results showed that APIs are the heart of today’s financial services and FinTech infrastructure. They allow FinTechs to embed banking into their apps and help banks deliver a more unified experience to customers who expect more from their bank. Details from this research show:

• 54 out of the 55 reverse engineered mobile apps contained hardcoded API keys and tokens, including usernames and passwords for third-party services.
• All 55 apps tested were vulnerable to MITM (Man in the Middle) attacks, which allowed Knight to intercept and decrypt encrypted traffic between mobile apps and backend APIs.
• One of the banks outsourced mobile app and API development. The developer reused the same vulnerable code that affected 300 other bank customers.
• 100% of the APIs tested were vulnerable to the OWASP Broken Object-Level Authorization (BOLA) vulnerability. This allowed Knight to change a bank customer’s ATM card number PIN code and deposit or withdraw money from their account.
• Due to the lack of authentication of API requests, the tested APIs were also vulnerable to Broken Authentication. This allowed Knight to transfer money to and from different bank accounts and change ATM PIN codes without authentication, so long as they knew the account numbers.
• The APIs tested were vulnerable to the Broken Authentication vulnerability, which allowed Knight to make API requests to other bank customer accounts without authentication.
• The APIs were deployed behind web application firewalls (WAFs) – the wrong security control, unable to detect logic-based attacks like authentication and authorization vulnerabilities.
• In several deployments, some banks were unable to find specific API endpoints affected by the vulnerabilities, indicating a clear problem with the visibility of their API attack surface.

Therefore, it’s clear that we need to focus on providing and maintaining secure APIs. This is especially important as processes become more digitized and barriers to entry for building applications lower due to initiatives like low-code and no-code development. The balance of knowledge is shifting to the process being digitized, rather than the system being developed.

Executing API security on an end-to-end basis requires the right tools. An effective end-to-end API security solution covers API security testing, API runtime security, and API security state management and inventory. You need to take a critical look at the available tools, since most WAFs and API gateways don’t cover development, testing, runtime monitoring and inventory.

Ideally, the API security solution should not impact the network or API performance by being able to detect API calls that mimic network traffic, identifying unknown APIs, and security threats. API security must cover all phases of the API lifecycle, from development through runtime to decommissioning. In part, security comes from processes that aren’t technically about security, like API inventories. Since unknown APIs are a risk, identifying them makes applications more secure. This is an end-to-end approach. The more comprehensive the API security measures, the more secure the entire environment will be.