Setting API security goals

Finally, in this chapter, let’s focus on the security goals that should be considered in API security initiatives. Different organizations will have different security priorities based on their business priorities – a financial service organization will favor high levels of security and strict governance, while a social media portal may have lower security requirements and favor feature delivery instead. No two organizations have the same goals.

The three pillars of security

The term API security has a broad scope, meaning different things to the beholder. IT security has traditionally used the CIA triad to characterize risks to systems. CIA is an acronym for Confidentiality, Integrity, and Availability, and has applications in APIs as follows:

• Confidentiality: For APIs, this implies that data is transmitted using secure transmission channels (typically, TLS) and that only permitted clients are able to access resources belonging to them (enforced by access controls).
• Integrity: For APIs, this requirement ensures that data cannot be modified or tampered with by unauthorized parties. Again, TLS and access controls are critical to ensuring integrity.
• Availability: APIs should be resilient and resistant to DoS attacks designed to take an API offline.

While a useful framework for considering API security, it should be considered in combination with the OWASP API Security Top 10 covered in Chapter 3.

Abuse and misuse cases

When considering API security, we primarily consider hacks or breaches where an adversary deliberately attacks an API and causes it to misoperate, due to inherent flaws. Such attacks are deliberately focused on using techniques we will explore in the Attacking APIs section.

However, there is another category of API security risk to be considered – namely, the abuse and misuse of APIs. Typically, in this category, we consider automated scripting, bot attacks, scrapers, and nuisance actors. While they do not have a high-risk rating (according to the CIA triad, for instance), they can have detrimental consequences for organizations.

Some typical examples include the following:

• Bots attempting to enumerate APIs and discover endpoints
• Scrapers trying to exfiltrate large volumes of data through automated pagination (typically, online retailers or estate agents are targets)
• Spammers or so-called troll farms abusing social media APIs
• Nuisance actors being mischievous by using APIs in unusual or unexpected ways (such as the automation of online auction sites)

Some of these types of abuse cases can be relatively difficult to either defend against (because they appear to be no different from normal users) or to detect.

Data governance

Data governance is tangential to API security but a key consideration for a holistic API security strategy. APIs are primarily conduits for data transfer between internal systems or organizations and consumers or partners. APIs simplify the ability of developers to expose increasing amounts of data almost at the click of a button. However, with this ease comes an increased risk of inadvertent or unintended data leakage, causing regulatory and compliance concerns.

A solid data governance program is essential to ensure that consumers (typically, API developers in this context) have full awareness of the data sensitivity and classification and apply the relevant controls to limit access, in line with regulatory and compliance concerns.

This is particularly applicable to the financial services and the medical industry, which increasingly face data disclosures via APIs.

A positive security model

Unlike web or mobile applications, APIs present a tremendous opportunity to radically shift the security paradigm. Traditionally, web or mobile security has relied on a negative security model, which means that a known bad actor is blocked, and everything else is allowed. Here, a deny list approach is used.

This approach – while long-established – has a significant disadvantage in that defenders do not know the full extent of all known bad actors. Clever attackers can construct payloads or inputs that appear to be valid inputs passing through the deny list; however, in the context of the application, they are dangerous. Think of the example of SQL Injection (SQLi) attacks where seemingly innocuous input is applied to a database, where it can have catastrophic consequences. The negative security model is characterized by both high false positives and false negatives.

API security turns this model around entirely, relying instead on an allow list that passes only known good actors to the API backend. This is the positive security model, which only allows data and operations specified by the OpenAPI contract to access the API. Anything else is simply blocked (via an API firewall, for example) before reaching the API. This approach offers a massive benefit for security — the instances of both false positives and negatives are greatly reduced. The positive security model has one major drawback, however – it is reliant on a fully formed OpenAPI contract to operate correctly. This may be challenging for organizations not embracing an API design-first approach. However, the positive security model promises to be game-changing for the world of API security.

Risk-based methodology

Finally, let’s conclude with an approach for prioritizing API security initiatives, which can be costly and time-consuming in large organizations. Probably the most frequently asked question is “Where do I start?” – security leaders are often stuck in a quandary when faced with a choice of trying to address their entire API portfolio (at great cost and a higher likelihood of failure), erroneously focusing on less important APIs (and wasting valuable security resources), or in extreme cases, simply not starting at all due to the enormity of the undertaking.

A common-sense approach to prioritizing an API security initiative is to use a risk-based methodology – start with the highest-risk APIs and work through to the lower risks, as budget permits.

Priority is dependent on several parameters, typically the following:

• Network access: Is the API publicly exposed, or is it on a more restricted network?
• Data sensitivity: How sensitive is the data and, hence, the impact of leakage? Personally Identifiable Information (PII) data (typically medical and financial data) is the highest sensitivity.
• Access control: Finally, how well protected is the API via access controls? Unauthenticated APIs are obviously the highest risk and should only be used for publicly accessible data.

Combining these three factors allows us to gain an approximate risk-based priority:

Figure 1.4 – Prioritizing API security via a risk profile

As a (slightly contrived) example, an unauthenticated API on a public network conveying medical records scores the maximum risk and, hence, becomes a priority.

While this is, at best, an approximate risk rating, it serves well to focus security activities where they will achieve the maximum return on investment.