A frequently quoted view is that there is no such thing asAPI security; it’s just an evolution of application security we have been practicing for the last two decades. However, I believe that it is a discrete and important discipline. Join me on the journey intoAPI security.

APIs are the backbone of a modern digital economy, allowing the exchange of critical data and the interconnectivity of different systems. APIs are the fuel that have fired digital innovation for the last decade. Given the critical role of APIs in our digital world, it is vital that they are secure. This chapter sets out the foundational concepts of APIs, particularly in relationto security.

In this chapter, we will examineexactlywhat is meant by API security and understand the key elements of this exciting and emerging security domain, covering topics such asthe following:

• The importance ofAPI security
• Understanding the basicsof APIs
• APIdata formats
• Elements of API security and APIsecurity goals

TheOpen Web Application Security Project(OWASP) published its first OWASP API Security Top 10 list in December 2019, and since then, theAPI security community has grown rapidly, with API security start-ups attracting significant investment and increasing interest from developers and security practitioners alike to learn resources on the topic. Unfortunately, during this period, there has also been a marked rise in the number of security incidents relating to insecure APIs. Recent analysis suggests a 681% rise in API attacks and that nearly one in two organizations has experienced a security incident relatedto APIs.

In a way,APIs are a victim of their own success– becauseof their rapid proliferation and the high economic value of the data they protect, they are now the most popular targetfor attackers.

We’ll now have a look at the so-called API economy and how the near-exponential growth in the number of APIs creates challenges for organizations as they become the favorite vectorfor attackers.

The growth of the API economy

To fully appreciate the importance of API security, let us first consider the growth of the so-called API economy. Let’s understand a bit more about what is meant by this term – Forbes defines an API economy as “an enabler for turning a business or organization into a platform.” A platform can leverage APIs to dothe following:

• Provide services and data to consumers fora price
• Consume services and data from other providers to enhanceyour business

What is the API economy?

The API revolution has led to the emergence of API-first businesses such as Twilio and has allowed other organizations to expose their core offerings via APIs (Google Maps is a good example). The disruptive nature of theAPI economy is best seen in the financial services industry – typically, this has been an industry resistant to innovation due to regulatory and compliance requirements. By using APIs to expose selected core services, banks can embrace new models without disrupting their core IT systems. By adopting open standards that can be certified – such as theOpen Banking API– banks can achieve interoperability while ensuring transactional integrity. The online money transfer service Wise uses APIs to provide B2B and B2C services and offersbanking-as-a-service(BaaS) to thirdparties by renting outtheir APIs.

Advantages of an API economy

There are several key benefits to anAPI economy:

• Reduced time-to-market: Organizations can use APIs to consume services from third parties rather than having to create those services themselves, resulting in faster developmentlife cycles.
• Drive value: Organizations can expose new and innovative services using APIs and opennew markets.
• Competitive advantage: By getting to market faster and using APIs to drive innovation, adopters can increase theircompetitive advantage.
• Improved efficiency: APIs allow IT teams to deliver immediate value by exposing APIs, rather than having to build and deploy mobile orweb applications.
• Security: Mobile and web applications expose a vast attack surface to adversaries. By focusing development on APIs, this attack surface can be reduced and focusgiven to the hardening and security ofthese APIs.

API adoption allows organizations to deliver more value and functionality while simultaneously reducing cost and timeto market.

The scale of the API economy

It is difficultto provide an accurate estimation of the scale of an API economy, and even if it was possible, this estimate would soon be invalidated due to the nearly exponential growth of the space. TheAPI community at Nordic APIs (https://nordicapis.com/20-impressive-api-economy-statistics/) has produced a survey on the scale of the API economy; the following are someheadline figures:

• Over90%of developersuse APIs
• The popular API test platform Postman has over46 millionAPI collections
• 83%of all internet traffic belongsto APIs
• There are over2 millionAPIGitHub repositories
• The API management market is valued at$5.1 billionin 2023
• 93%of communication service providers useOpenAPI specifications
• 91%of organizations have had an APIsecurity incident

On the back of a growing API economy, major capital investment has poured into the market for API tool vendors, management platforms, andsecurity tools.

Challenges to an API economy

The rapid adoption of APIs brings with it several challenges in addition to the benefits. The first challenge is that of inventory — because APIs can be easily built and deployed and have a finite lifetime, organizations are struggling to keep track of their API inventory, resulting in shadow (hidden) and zombie (outdated) APIs.

The second challenge is that of governance — as APIs proliferate, organizations face challenges with governing the development and deployment process, ensuring that data and privacy requirements are met and that the API life cycle is managed from cradleto grave.

The biggest challenge, however, is that of security. As noted earlier in this section, APIs can reduce an organization’s overall attack surface; however, this comes at the cost of a new security paradigm – APIs are a new attack surface, and the threats are different. In the next section, we’ll explore these security challenges inmore detail.

APIs are popular with developers

Developers love APIs — nearly all developers work with APIs and nearly all modern architectures are API-centric. While containerization has driven the breakdown of the monolith and the emergence of microservices, it is APIs that form the connecting tissue betweenthese services.

The benefit of APIs to developers are numerous, includingthe following:

• They form an abstraction between services and allow encapsulationof functionality.
• They define a clear interface via an OpenAPI specification that serves as a contract forthe API.
• They allow a truly polyglot environment where different APIs can be implemented in the most suitable programming language for the taskat hand.
• They simplify data exchange as APIs generally use JSON, XML,or YAML.
• They facilitate ease of testing, using tools such as Postman or tools that can validate API functionality against theOpenAPI Specification.
• They propel ease of development. The API development ecosystem is rich with powerful tooling for the development and testing of APIs. Moreover, fully featured APIframeworks exist for most modernprogramming languages.

These factors have fueled theAPI-firstparadigm where applications are built in a bottom-up approach, starting with the APIs, then thebusiness logic, and theuser interface(UI) last.

APIs are increasingly popular with attackers

While APIs are undoubtedly popular with developers, they are even more popular with attackers. Gartner reports that APIs are the number one attack vector for cybercriminals in 2022, and barely a week goes by without an API breach or vulnerabilitybeing disclosed.

There are several key reasons why APIsare a favoredattack target:

• APIs are likely to be publicly accessible: By their nature, APIs are intended to be interconnected with other systems, requiring them to be exposed on public networks. This facilitates easy discovery and attackby adversaries.
• APIs are often well documented: To aid easy adoption and integration, good APIs should be documented using tools such as theSwagger UI. Unfortunately, such documentation can also be invaluable to attackers in understanding how theAPIs work.
• API attacks can be automated: API interaction isheadless(not requiring a UI or human interaction) and can easily be automated with scripts or dedicated attack tools. APIs are, in many cases, easier to attack than mobile orweb applications.
• APIs expose valuable data: Most importantly, APIs are designed to allow access to key data assets (PII, financial, or market data), which are likely to be the highest prize for an attacker. Attackers increasingly attack APIs that inadvertently expose excessive data or allow mass exfiltration, which might not be the case with awell-crafted UI.

Your existing tools do not work well for APIs

The relatively recent emergence of APIs as the de facto conduit for application connectivity poses significant challenges to security teams and testers. Much of the existingapplication security(AppSec) toolingthat exists was designed in an era when web applications were the primary asset to be protected. Commonsecurity tools such asstatic application security testing(SAST),dynamic application security testing(DAST), andsoftware composition analysis(SCA) are far less effective in assessing APIs than they are with web ormobile applications.

Traditional perimeter protections such as network firewalls orweb application firewalls(WAFs) are ineffective in protecting APIs, since they lack the context of the API interface and the expected request and response traffic. Such tools tend to be high in both false positives andfalse negatives.

More modern API technologies, suchasAPI management portals(APIMs) and gateways, are essential for the operation of APIs at scale, but while they do provide security features, they do not address allattack vectors.

The key takeaway is that while tools are important as part of a defense strategy, they need to be augmented by solid defensive design and coding techniques — this is the focus of the final section ofthis book.

Developers often lack an understanding of API security

It is important to understand why insecure code exists in the first place if we want to addressthe problem.

Developers are, by nature, creative problem solvers who thrive on a challenge – unfortunately, this leads them to beover-optimistic, which can lead them to take shortcuts and optimizations, or perhaps work to unrealistic delivery schedules. This is so-calledhappy pathcoding, wheredevelopers do not fully appreciate how their code could fail or be misused by an attacker, sometimes withdire consequences.

Coupled with over-optimism is a sense ofover-confidence– developers will assume they fully understand a problem but may be unaware that they are missing some crucial detail or subtlety, which again can have adverse effects. An example is the adoption of a new API framework and not carefully considering the default settings and deploying avulnerable product.

Developers will often have a misplaced sense that bad things only happen to other people and not them. Despite witnessing examples of well-known breaches, many developers believe they will never fall victim to a similar misfortune. This general phenomenon is known as theschadenfreude effect.

The development process can be stressful with constant pressure to deliver to schedule, and this can result in compromising full implementation in favor of meeting deadlines. For example, this can include the omission of error handling code or data validation with the intent of coming back to implement them in later releases. With time pressures, this rarely happens, and code is often left in anincomplete state.

Often, developers inherit a code base to maintain that may contain significanttechnical debt or legacy code. Without a full understanding of the system and its complexities and foibles, developers may be disinclined to make changes to the code base in case theybreak functionality.

Before we can understandhow to secure APIs, we need to dive into the building blocks of APIs. This section will cover the somewhat challenging topics of cryptography, hashing and signatures, encoding, and transport layer security. We will not go into a lot of detail, but it is important to graspthese basics.

Rate limiting

Public APIs are exposed to theinternet and can easily be discovered by adversaries. One of the simplest attacks against an API is adenial-of-service(DoS) attack, in which automation is used to repeatedly and persistently attempt to access an API. Sustained DoS attacks can lead to the exhaustion of server resources, leading to a failure of the API or, most commonly, denying legitimate access tothe API.

Brute-force attacks can also be usedinaccount takeover(ATO) attacks, where either a sign-up endpoint or a password reset endpoint are flooded in attempts to guess passwords or hashes, using adictionary attack(where a list of commonly used passwordsis used).

Both types of attacks can be mitigated using rate-limiting technology, which limits repeated and frequent access from a particular IP address to a given endpoint. Rate-limiting applies a timeout window on the transactions and will return a429 Too ManyRequestserror.

Cryptography

Cryptography is a foundationalelement in securing data electronically – most simply, it is a mathematical transformation applied to data. Typically,cleartext(unencrypted) is transformed intocyphertext(encrypted), using an algorithm and a key. The cyphertext is no longer recognizable as the original cleartext and cannot be reverse-engineered to reveal the original cleartext without using the inverse transformation (decrypted), using the same algorithm andthe key.

The choice of algorithm depends on the application; two broad types of algorithmsare used:

• Symmetric algorithm: In this type, the same key is used to encrypt and decrypt data. The benefit ofsymmetric ciphers is that they are fast and safe; however, they pose a challenge in terms of the distribution of the shared key. Common symmetric key algorithms are DES, AES,and IDEA.
• Asymmetric algorithm: In thistype, different keys are used to encrypt (using the public key) and decrypt (using the private key) data. Common asymmetric key algorithms are DDS, RSA,and ElGamal.

A fundamental challenge with cryptography is the exchange (and management) ofkeysbetween both parties. To this end, robust key-exchange protocols have been developed to securely exchange keys that prevent an eavesdropper from accessing keys in transit. The Diffie-Hellman exchange is the mostused protocol.

Cryptography provides thefollowing benefits:

• Authentication: By usingpublic-key cryptography, it is possible to verify the identity of the originatingparty by using their public key to confirm they signed a message with their private key, which only they can access. By usingcertificates, it is possible to verify the validity (or trust) associated with public keys – this is thefoundation ofTransport LayerSecurity(TLS).
• Nonrepudiation: Using cryptography principles, transactions or documents can be audited to verify which parties had access to the resources. This prevents a receiving party from denying receipt; typically, this is used for bank transactions ordocument signatures.
• Confidentiality: The most obvious advantage of cryptography is to ensure that data is kept private, both in transit and at rest in storage. Only persons in possession of a valid key can decrypt and accessthe data.
• Integrity: Finally, cryptographycan be used to ensure the integrity of data, verifying that it has not been modified in transit. By transmitting afingerprintof the data along with it, the receiver can verify that the received data is the same that was transmitted by re-calculating the fingerprint and validatingit against theone received.

Hashes, HMACs, and signatures

An important application of cryptography principles relates to ensuring the integrity of messagesin transit.

Hashesare themost elementary technique, in which a block of data is passed through an algorithm to produce adigestof the data; typically this is a fixed-length string much shorter than the input data. Common hashing algorithms include SHA2 and MD5. Key properties of hash functions are that they areone-way functionsor irreversible (the input cannot be obtained from the digest, and the digests are unique so that no two blocks of data will produce the same digest). Hashes are used to verify the integrityof data.

Hashed Authentication Message Codes(HMACs) aresimilar to hashes in that they produce a digest that is then encrypted with a symmetric algorithm and passed to the recipient. If the recipient has the correct key, they can decrypt the digest and verify the integrity of the data, and also the authenticity of the sender (via theirshared key).

Signaturesare the final piece of the puzzle – similar to HMACs, these use an algorithm to encrypt the digest; however, in this case, it is an asymmetric algorithm. The private key is used for encryption, and at the receiver end, the public key of the sender is used to decrypt andverify the integrity. Using robust principles ofpublic key infrastructure(PKI), public keyscan be trusted (their ownership canbe verified).

The following table summarizes the differences between thethree types:

Table 1.1 – A comparison of digest types

Transport security

TheTLSprotocol is a transport-level cryptographic protocol to ensure secure communications over aTCP/IP network. An encrypted transport layer is essential for APIs to ensure that attackers are unable to eavesdrop on data or tokens over the network and to ensure that the client can validate the identity of the server (via certificate validation). Certificate management has usually presented challenges to organizations; however, with the emergence of providers such as Let’s Encrypt, certificate deployment and management have become alot simpler.

Encoding

The finalbuilding block is that ofencoding, whichinvolves changing the representation of data for the purposes of storage or transmission. Encoding converts the character set of input data to a format that can be safely stored or transmitted, and decoding converts that data back to itsoriginal format.

This concept is best understood by looking at a few commonencoding schemes:

• HTML encoding: In HTML, certain characters have special significance – for example,<and>. If a text blockcontains these characters, it will change the structure of the rendered HTML, which is undesirable. By encoding these special characters in another format ("<"and">"), they can be safely rendered in an HTML document, where they will be displayed correctly as<and>but stored in adifferent form.
• URL encoding: Similarly, ina URL, only the ASCII character set is allowed; all other characters areforbidden. Unfortunately, path locations may contain such characters (spaces and underscores, for example). By encoding these to an ASCII text representation, it is possible to get a valid URL version – for example, a space is convertedto%20.
• ASCII, UTF8, and Unicode: Text can be represented in a number of different formats and can be converted from one to the other, dependingon the platforms and localesin use.
• Base64: This is a commonly used encoder to transform binary data to text data suitable for transmissionover HTTP.

Encoding does not use a key to perform the transformation but, rather, a fixed algorithm, and any content that has been encoded can be decoded to produce exactly the sameoriginal content.

Encoding versus encryption

A common misunderstanding is the difference between encoding and encryption. They are two very different topics, solvingdifferent problems.

Encoding transforms data from one representation to another using a fixed algorithm. No keys are used, and the encoded data can be trivially converted back to the original format. It does not offer any form of integrity orconfidentiality functions.

Encryptionperforms a transformation of data using a key; the resultant output does not resemble the input at all, and the only way the original data can be obtained is by applying the reverse decryption function using the same key. Encryption does not transform the representation or character set ofthe data.

Finally, in this section, let’stake a quick look at common data formats used in APIs. For REST APIs, information is transferred in plain text format (although this information may be encoded), either as key-value pairs as request parameters, one or more headers, or as an optional request body. Responses consist of a status and an optionalresponse body.

XML

eXtensible Markup Language(XML) is the original heavyweight format for internet data storage and transmission. The format is designed to be agnostic of data type, separates data from presentation, and is of courseextensible, not being reliant on any strict schema definition (unlike HTML, which uses fixed tagsand keywords).

Although XML was dominant several years ago, it suffered from some significant drawbacks, namely complexity and large data payloads. These two factors make it difficult to process and parse XML on resource-limited systems. XML is still encountered, although much less soin APIs.

A simple example of XML shows the basic structure of tagsand values:

<note>  <to>Colin</to>  <priority>High</priority>  <heading>Reminder</heading>  <body>Learn about API security</body></note>

JSON

Javascript Object Notation(JSON) is now the dominant transferformat for data over HTTP, particularly in REST APIs. JSON originated as a lightweight alternative to the more heavyweight XML format, being particularly efficient with transmission bandwidth andclient-side processing.

Data is represented by key-value pairs, with integer, null, Boolean, and string data types supported. Keys are delimited with quotes, as are strings. Records can be nested, and array data is supported. Comments are not permitted inJSON data.

A simple example of JSON shows the key-valuepair structure:

{  "name": "Colin",  "age": 52,  "car": null}

YAML

YAML Ain’t Markup Language(YAML) isanother common internet format, similar to JSON in its design goals. YAML is in fact a superset of JSON, with the addition of some processing features. JSON can be easily converted to YAML, and often, they are used interchangeably, depending on personal preference, particularly forOpenAPI definitions.

The same data from the JSON example can be expressed in YAMLas follows:

---name: Colinage: 52car:

OpenAPI Specification

The final format we need to understand istheOpenAPI Specification(OAS), which is a human-readable (and machine-readable) specification for defining the behavior of an API. The OpenAPI Specification is an open standard run under the auspices of the OpenAPI Initiative. Previously, the standard was known as Swagger (aka version 2) but has now been formalized into an open standard, and currently, version 3.0 is in general use, with version 3.1 due imminently at the timeof writing.

An OAS definition can be expressed either as YAML or JSON and comprises several sections, asshown here:

Figure 1.1 – OpenAPI Specification sections

Using an OAS definition at the inception of the API life cycle (referred to asdesign-first) offers several key benefits, namelythe following:

• Description validation and linting: Parsers and audit tools can automatically validate a definition to confirm its correctnessand completeness.
• Data validation: Request and response data can be fully specified, allowing validation of API behaviorat runtime.
• Documentation generation: Documentation can be automatically generated from a definition, including a test UI, allowing the API tobe exercised.
• Code generation: Tools exist that allow the server and client code stubs to be generated in a variety of languages, easing the burdenon developers.
• Graphical editors: Fully featured graphical editors make it a simple task to design OAS specifications in an interactive,intuitive manner.
• Mock servers: OAS definitions can be used to build mock servers that simulate the behavior of an actual API backend. This is extremely useful in the early stages of API developmentand integration.
• Security analysis: Most importantly for us is the security benefits that the use of an OAS definition brings – definitions can be examined for security constraints (authorization and authentication, for example), and deficiencies can be highlighted. Data structures can be fully specified to allow the validation of data, preventing excessiveinformation exposure.

A sample OAS definition is shown in the following snippet. This is an example of a bare-minimum specificationof an API and includes the following in theheader section:

• TheOpenAPI version
• Information metadata
• Server information, including thehost URL:

  {    "openapi": "3.0.0",    "info": {        "version": "1.0.0",        "title": "Swagger Petstore",        "license": {            "name": "MIT" }    },    "servers":[    {      "url": http://petstore.swagger.io/v1    }],    ..

The next section in theOAS definition describes an endpoint, showing details such asthe following:

• The endpointpath name
• The HTTP method tobe used
• Request parameters
• Status codes
• Theresponse format:

      "paths": {        "/pets": {            "get": {               "summary": "List all pets",               "operationId": "listPets",               "parameters": [               { "name": "limit",                 "in": "query",                 "description": "Maximum items (max 100)",                 "required": false,                 "schema": {                   "type": "integer",                   "format": "int32"                  } } ],                "responses": {                  "200": {                    "description": "A paged array of pets",                    "headers": {                      "x-next": {                        "description": "Next page",                         "schema": {                          "type": "string                        } } },                     "content": {                     "application/json": {                       "schema": {                       "$ref": "#/components/schemas/Pets"                     } } } },                     ..

At this point, we understand the building blocks of APIs and the associated data formats. It is now time to look at the elements ofAPI security.

API security is a complex topic and comprises many elements — a successful API security initiative should be built upon a solid foundation of a DevOps practice and a balanced AppSec program. Just like a house, the strength of the overall structure is dependent on a solid foundation – without these in place, an API security initiative mayprove challenging.

Good security is built on a multi-layer system – this is thedefensein-depthapproach.

It is important to remember that API security is quite different from what has come before with web application security. This means that using existing tools and practices may be insufficient to produce secure APIs. Dedicated API security solutions must be deployed in addition to traditional AppSec tools to provide the optimum coverage and protection specificto APIs.

The elements of the API security hierarchy areshown here:

Figure 1.2: The elements of API security

Let’s explore each of the layers of APIsecurity briefly.

DevOps

DevOps is awell-establishedset of practices to facilitate modern software systems, characterized by close relationships between the development and operations teams to improve methodology and practices and leverage the benefits of automation. DevOps is considered a continuous process with continuous improvements across several key domains in theSoftware Development Lifecycle(SDLC), asshown here:

Figure 1.3: The DevOps cycle

DevOps offers many benefits to the delivery of software, includingthe following:

• Improved collaborationand trust
• Fasterrelease cycles
• Reduced timeto repair
• Higher levelsof automation
• Use of standard processes, including testingand deployment

From the perspective of API security, the key benefit of DevOps is the ability to build APIs in a deterministic fashion using a standard process. Using standardContinuous Integration / Continuous Delivery(CI/CD) pipelines, API security testing and validation tooling can be injected into the build process to ensure that all deployed APIs have had the specified security checks and controls applied to them. APIs by their nature are well suited to automated testing, and the CI/CD pipeline is the ideal place forthis activity.

SAST, DAST, SCA, and WAFs

Static application security testing(SAST),dynamic application security testing(DAST),software composition analysis(SCA), andweb application firewalls(WAFs) formthe vanguard of traditionalapplicationsecurity programs.

The security of any software can be improved by the judicious use of such tools,as follows:

• SAST can detect basic flaws in source code at the timeof development
• DASTcan detect application vulnerabilitiesat runtime
• SCA can detect the use of vulnerable componentsand libraries
• WAFscan afford some level of protection against certainattack types

SAST can detect common coding vulnerabilities in API code (such as injection flaws) but will not detect API-specific flaws (such as broken authentication or authorization), since the SAST engine does not have contextual awareness of the underlying API code. Similarly, DAST is able to detect certain API vulnerabilities (such as a lack of rate limiting) but lacks the context to understand the API requestsand responses.

WAFs are a mature technology for protecting web applications and offer some protection for APIs as well. They operate in line with traffic utilizing a so-calledallow listto block suspected malicious traffic and allowing everything else. They can be configured to operate in monitor mode (passive) or blockingmode (active).

Organizations typically have dedicated security teams tasked with deploying and operating these tools within development teams. These teams should evaluate dedicated API security tools to complement some of the gaps that exist withthese tools.

API management and gateways

API gateways are the workhorse of the API industry, providing a unified external interface to public clients and traffic routing to the relevant internal API backends after having performed transformation and conversion. Gateways are also responsible for network-levelcontrols such as SSL termination, rate-limiting, IP address restrictions, and load balancing. Gateways can also implement security features such as JWT validation andidentity management.

Some of the shortcomings ofAPI gateways includethe following:

• API gateways provide a central point of entry for API traffic and are effective at acting as a gatekeeper at thefront doorof the customer infrastructure; however, they are less effective at protecting what goes on behindthe door
• Gateways are ineffective at protecting against several of the OWASP API Security Top10 vulnerabilities
• Gateways can be inefficient at providing security processing functions such astraffic inspection

Typically, API managementportals provide a level of API management on top of a gateway, allowing organizations to control their inventory, versioning, life cycle, and end-user experience by providingAPI catalogs.

Some of the shortcomings of API management platforms includethe following:

• APIM portals areeffective for providing a central view of an API inventory and also a single point of deployment forAPI policy
• Effective APIM deployment is contingent on development teams embracing a design-first approach and enrolling their APIs into acentral portal

Both API management portals and gateways are vital components of an API security strategy, but their limitations should be borne in mind as part of theoverall strategy.

API security platforms

The growth of API adoption has spawned several dedicated API security platforms, with the specific intent of addressing API security as afirst-class citizen.

These platforms takedifferent perspectives of securing APIs, includingthe following:

• Continuousmonitoring of API traffic to detect emergent threats usingmachine learning(ML) andartificial intelligence(AI) technology
• Dedicated API firewalls that can protect APIs by enforcing the OpenAPI contract – this is the positive security model covered in thenext section
• Scanning APIs to validate the API behavior against anOpenAPI contract
• Providing audit tools to ensure OpenAPI contracts adhere to best practices for dataand security

Dedicated API security tools are vital to providing the final layer of API security. Now that we understand the elements of API security, let us conclude this chapter by setting APIsecurity goals.

Finally, in this chapter, let’s focuson 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 thesame 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 theCIA triadto characterize risks to systems.CIAis an acronym forConfidentiality, Integrity, and Availability, and has applications in APIsas 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 byaccess 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 toensuring integrity.
• Availability: APIs should be resilient and resistant to DoS attacks designed to take anAPI offline.

While a useful framework for considering API security, it should be considered in combination with the OWASP API Security Top 10 covered inChapter 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 theAttackingAPIssection.

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 consequencesfor organizations.

Some typical examples includethe following:

• Bots attempting to enumerate APIs anddiscover endpoints
• Scrapers trying to exfiltrate large volumes of data through automated pagination (typically, online retailers or estate agentsare targets)
• Spammers or so-calledtroll farmsabusing socialmedia APIs
• Nuisance actors being mischievous by using APIs in unusual or unexpected ways (such as the automation of onlineauction sites)

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

Data governance

Data governance is tangential toAPI 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 andcompliance 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 andcompliance concerns.

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

A positive security model

Unlike web or mobile applications, APIspresent a tremendous opportunity to radically shift the security paradigm. Traditionally, web or mobile security has relied on anegative security model, which means that a known bad actor is blocked, and everything else is allowed. Here, adeny listapproachis 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 ofSQL 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 andfalse 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 thepositive 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 bechallenging for organizations not embracing an API design-first approach. However, the positive security model promises to be game-changing for the world ofAPI 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 ofthe 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, asbudget permits.

Priority is dependent on several parameters, typicallythe following:

• Network access: Is the API publicly exposed, or is it on a morerestricted 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 thehighest 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 publiclyaccessible data.

Combining these three factors allows us to gain an approximaterisk-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, becomesa priority.

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

We have covered a lot in this first chapter. APIs are the lifeblood of a modern application economy and, unfortunately, are a favorite target for attackers due to the high value of data that they convey. We now understand the core building blocks of APIs, how developers are vital in the journey to building secure APIs, and the various elements of a secureAPI initiative.

In the next chapter, we are going to explore in greater detail exactly how an API is constructed, how they work, and critically, how theyare secured.

• For further perspectives on the API economy, the following providegood insight:
  • https://marker.medium.com/the-api-economy-in-finance-payoffs-of-getting-connected-c5c6aeb34c57
  • https://www.forbes.com/sites/forbestechcouncil/2021/09/10/how-to-succeed-in-the-api-economy/?sh=a2b84a544b98
  • https://nordicapis.com/20-impressive-api-economy-statistics/
• The following will help to understand why SAST and DAST tools are insufficient tosecure APIs:
  • https://thenewstack.io/application-security-tools-are-not-up-to-the-job-of-api-security/
  • https://restfulapi.net/
• The following will help to understand how Airbnb implements itsdata governance:
  • https://medium.com/airbnb-engineering/data-quality-at-airbnb-e582465f3ef7
• Further information on the different typesof APIs:
  • https://developer.mozilla.org/en-US/docs/Web/HTTP
  • https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
• OpenAPIspecification documentation:
  • https://spec.openapis.org/oas/v3.1.0
  • https://spec.openapis.org/oas/v3.0.0