Defending APIs E-Book

Colin Domoney

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 475

Veröffentlichungsjahr: 2024

Beschreibung

Along with the exponential growth of API adoption comes a rise in security concerns about their implementation and inherent vulnerabilities. For those seeking comprehensive insights into building, deploying, and managing APIs as the first line of cyber defense, this book offers invaluable guidance. Written by a seasoned DevSecOps expert, Defending APIs addresses the imperative task of API security with innovative approaches and techniques designed to combat API-specific safety challenges.
The initial chapters are dedicated to API building blocks, hacking APIs by exploiting vulnerabilities, and case studies of recent breaches, while the subsequent sections of the book focus on building the skills necessary for securing APIs in real-world scenarios.
Guided by clear step-by-step instructions, you’ll explore offensive techniques for testing vulnerabilities, attacking, and exploiting APIs. Transitioning to defensive techniques, the book equips you with effective methods to guard against common attacks. There are plenty of case studies peppered throughout the book to help you apply the techniques you’re learning in practice, complemented by in-depth insights and a wealth of best practices for building better APIs from the ground up.
By the end of this book, you’ll have the expertise to develop secure APIs and test them against various cyber threats targeting APIs.

Leseprobe

Defending APIs

Uncover advanced defense techniques to craft secure application programming interfaces

Colin Domoney

Defending APIs

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Prachi Sawant

Book Project Manager: Ashwin Dinesh Kharwa

Senior Editor: Isha Singh

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Vijay Kamble

DevRel Marketing Coordinator: Marylou De Mello

First published: February, 2024

Production reference: 112012024

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-80461-712-0

www.packtpub.com

To everyone tasked with developing or securing software: you have an awesome responsibility, and this book is dedicated to making that just a little bit easier.

For my late father, Athol, who from my earliest memory encouraged me to apply myself fully to my learning and education, and would be very proud of what I have achieved.

Colin Domoney

Foreword

In a digital world completely reliant on APIs, mastering their security is not just a necessity, it’s an imperative. Every organization is dependent on internet technology to function and that technology is dependent on APIs that were created by the developers at those organizations or the developers at their technology suppliers. Yet, these developers and the security professionals who need to work with them to manage this increasingly important risk lack knowledge on how to effectively secure APIs. Daily, we see the downfall of this missing knowledge. Data breaches and ransomware are endemic. One of the biggest causes is the vulnerable APIs that expose an organization’s data, network, and transactions to the internet, and attackers!

It’s my privilege to introduce Colin Domoney’s Defending APIs,” a book that stands as a testament to the critical importance of securing APIs in today’s interconnected landscape. Colin, with his vast experience in software development and security, delves deep into the world of APIs. His journey through the intricacies of API vulnerabilities, attack strategies, and robust defense mechanisms is both enlightening and essential. This book is not just about theories; it’s a reflection of real-world scenarios, offering practical insights and solutions.

Understanding the fundamentals of how a technology is designed and implemented is critical to understanding how to secure it. Part One lays a foundational understanding of API security, addressing its holistic nature and dissecting core components such as protocols and data formats. It also dives into the OWASP API Security Top 10, providing insights into common vulnerabilities and high-profile breaches.

It is necessary to understand how common failures in secure design and implementation are taken advantage of by attackers. Part Two focuses on attacking APIs, equipping readers with knowledge of adversarial techniques and tools, crucial for crafting robust defenses.

With an understanding of the technical mechanics of APIs and how attackers operate in the real world, you will be ready for the final segment. In Part Three, Colin imparts an in-depth guide on defending APIs, emphasizing tools and techniques across the development lifecycle and exploring the future of API security in microservices architecture.

As someone who has dedicated a career to advocating for secure software design, I find Colin’s approach in this book particularly compelling. He bridges the gap between understanding the problem and implementing effective solutions, making this book a valuable resource for both security professionals and software developers alike.

Defending APIs is a journey through the complexities of API security, guided by a seasoned expert. Colin’s work here is not just informative; it’s inspiring, pushing us to think differently about how we protect this important glue that holds together our shared digital infrastructure.

In a time where digital security is paramount, this book serves as a beacon, guiding the way toward a more secure digital future. I highly recommend it to anyone who’s serious about understanding and implementing API security in their organization.

Chris Wysopal

Veracode co-founder and CTO

December 31, 2023

In the famous words of Marc Andreessen, software is eating the world. In that world, APIs are the entry door to absolutely everything, from your bank to your brand-new washing machine, moving data across a wide variety of systems. Data is the new gold, and once you know that, you understand why APIs are the target of so many cyber-attacks.

When we started 42Crunch, we had to convince people APIs were a new attack target and, more importantly, a different attack target. Architectures based on APIs are different and, as such, you need new ways to protect them. The traditional protection measures at the edge of the network and vulnerability detection via code analysis at the end of the development cycle simply won’t work and won’t scale for API-based applications.

Fast-forward five years and API security is now one of the hottest topics in IT, with every enterprise realizing they need to work diligently to secure their API development lifecycle.

Colin has helped numerous 42Crunch customers build a strategy toward developing rugged APIs and authored our API security maturity model. His experience, looking at the issue both from an attacker and defender perspective, is condensed into his book. Should you be a CISO building a new security program for APIs or a developer trying to understand how to build better, resilient APIs, this book is for you.

I wish you a great journey securing your APIs, with Defending APIs by your side!

Isabelle Mauny

42Crunch co-founder and CTO

January 2, 2024

Contributors

About the author

Colin Domoney has a long and varied career both in development and, more recently, as an advocate for secure software systems. His career started with developing mission-critical military and medical systems in South Africa, where he learned the importance of developing systems that are rugged and robust. He has applied this experience across multiple industries, including automotive, financial services, consumer electronics, and others.

Most recently, he has applied his skills to building large-scale application security programs for some of the largest organizations globally, helping them scale their software security capabilities. As an independent security consultant, he specializes in coaching and teaching developers how best to build secure software. He is the chief technology evangelist at 42Crunch, focused on advocating for secure API development best practices and developing APIs that are secure by design. He is an avid learner and technologist at heart and is happiest discovering new technologies or approaches to securing software.

In addition to his advocacy role, where he is a regular conference presenter and webinar host, Colin is also the curator of the APISecurity.io newsletter, featuring the latest in API security news. It was through this newsletter that he found a passion for API security in particular, leading to the journey that has led to the book you have in front of you now. He is currently working on a course and workshop to accompany the book.

About the reviewer

Peter Chestna has been a software engineer for over 30 years. For more than half his career, he has specialized in application security, commonly called AppSec, from both the vendor and practitioner side. Starting as a developer at Veracode in 2006, he rose through the ranks to lead the SaaS engineering delivery team. He left to transform and lead the AppSec program at Bank of Montreal (BMO) for several years before returning to the vendor side to become the CISO of North America at Checkmarx.

A lifelong learner, he devotes significant time to reading about psychology and leadership, software development practices, and cybersecurity. He speaks internationally at Agile, DevOps, and security conferences, with a particular affinity for DevOpsDays. Pete has been granted three patents.

Table of Contents

Preface

Part 1: Foundations of API Security

1

What Is API Security?

Why API security is important

The growth of the API economy

APIs are popular with developers

APIs are increasingly popular with attackers

Your existing tools do not work well for APIs

Developers often lack an understanding of API security

Exploring API building blocks

Rate limiting

Cryptography

Hashes, HMACs, and signatures

Transport security

Encoding

Examining API data formats

Understanding the elements of API security

DevOps

SAST, DAST, SCA, and WAFs

API management and gateways

API security platforms

Setting API security goals

The three pillars of security

Abuse and misuse cases

Data governance

A positive security model

Risk-based methodology

Summary

Further reading

2

Understanding APIs

Understanding HTTP fundamentals

Uniform Resource Locator

Requests

Responses

Methods

Status codes

Sessions

Exploring the types of APIs

REST

GraphQL

RPC

SOAP

WebSockets

Access control

No authentication

HTTP authentication

AWS keyed-HMAC authentication

Session cookies

API keys

OAuth 2.0

Access control best practices and methods

Using JWTs for claims and identity

Summary

Further reading

3

Understanding Common API Vulnerabilities

The importance of vulnerability classification

Exploring the Open Worldwide Application Security Project API Security Top 10

Object-level vulnerabilities

Authentication vulnerabilities

Function-level vulnerabilities

Data vulnerabilities

Configuration vulnerabilities

Implementation vulnerabilities

Vulnerabilities versus abuse cases

Exploring abuse cases

Business logic vulnerabilities

Preview of the Open Worldwide Application Security Project API Security Top 10 2023

Summary

Further reading

4

Investigating Recent Breaches

The importance of learning from mistakes

Examining 10 high-profile API breaches from 2022

1–Global shipping company

2–Campus access control

3–Microbrewery application

4–Cryptocurrency portal

5–Dating application

6–The All in One SEO WordPress plugin

7–X account information leakage

8–Home router

9–Remote access to two popular vehicles

10–Smart Scale

Key takeaways and learning

Summary

Further reading

Part 2: Attacking APIs

5

Foundations of Attacking APIs

Technical requirements

Understanding API attackers and their methods

Interacting with APIs

Finding API keys

Enumeration and discovery of APIs

Fuzzing API endpoints

Attacking JWTs

Mastering the tools of the trade

CLI clients (HTTPie/cURL)

Postman

Browser tools

Burp Suite

Reverse proxies

Learning the key skills of API attacking

Building a laboratory

Hacking vulnerable APIs

Training courses

Summary

Further reading

6

Discovering APIs

Technical requirements

Passive discovery

Google

Offensive security Google database

Other API-specific searchable databases

Code analysis techniques

Active discovery

Network discovery and scan

OWASP ZAP

Burp Suite

Reverse-engineering mobile apps

Postman

Implementation analysis

Verbose error and debug messages

OS and framework enumeration

Timing or volume attacks

Utilizing online tools such as BuiltWith or Wappalyzer

Evading common defenses

Summary

Further reading

7

Attacking APIs

Technical requirements

Authentication attacks

Insecure implementation logic

Attacking design weaknesses

Authorization attacks

Object-level authorization

Function-level authorization

Data attacks

Injection attack

Detecting injection vulnerabilities

SQL injection

NoSQL injection

Command injection

Path traversal

Server-side request forgery

Other API attacks

API abuse

Unrestricted access to sensitive business flows

Business logic attacks

Summary

Further reading

Part 3: Defending APIs

8

Shift-Left for API Security

Technical requirements

Using the OpenAPI Specification

Data

Security

Generating client and server code

Leveraging the positive security model

Conducting threat modeling of APIs

Automating API security

CI/CD integration

Semgrep

Thinking like an attacker

Summary

Further reading

9

Defending against Common Vulnerabilities

Technical requirements

Authentication vulnerabilities

Handling JWTs securely

Implementing OAuth2

Password and token hardening

Securing the reset process

Handling authentication in code

Authorization vulnerabilities

Object-level vulnerabilities

Function-level vulnerabilities

Using authorization middleware

Data vulnerabilities

Excessive data exposure

Mass assignment

Implementation vulnerabilities

Injection

Server-Side Request Forgery

Insufficient logging and monitoring

Protecting against unrestricted resource consumption

Defending against API business-level attacks

Unrestricted access to sensitive business flows

Unsafe consumption of APIs

Summary

Further reading

10

Securing Your Frameworks and Languages

Technical requirements

Managing the design-first process in the real world

Using code-generation tools

Swagger Codegen

OpenAPI Generator

Summary

Further reading

11

Shield Right for APIs with Runtime Protection

Technical requirements

Securing and hardening environments

Container images

Operating systems

Using WAFs

Understanding the Next-Generation Firewall (NGWAF) and Web Application API Protection (WAAP) products

Using API gateways and API management

Implementing security patterns in the Kong API gateway

Best practices for API gateway protection

Deploying API firewalls

API monitoring and alerting

Selecting the correct protections for your APIs

Summary

Further reading

12

Securing Microservices

Technical requirements

Understanding microservices

Securing the foundations of microservices

Securing the connectivity of microservices

Access control for microservices

Running secure microservices in practice

Summary

Further reading

13

Implementing an API Security Strategy

Ownership of API security

Understanding your stakeholders

Roles and responsibilities

The 42Crunch maturity model

Inventory

Design

Development

Testing

Protection

Governance

Planning your program

Establishing your objectives

Assessing your current state

Building a landing zone for APIs

Running your program

Building your teams

Tracking your progress

Integrating with your existing AppSec program

Your personal API security journey

Summary

Further reading

Index

Other Books You May Enjoy

Preface

In today’s hyper-connected digital world, APIs are ubiquitous in providing the connecting tissue between systems and services. The growth of APIs continues at an exponential pace, with almost every developer either responsible for creating APIs of their own or consuming APIs as part of their solution. Unfortunately, attackers have shifted their focus to attacking APIs first, and the alarming rise in API incidents and breaches is testimony to the challenges developers face in producing APIs that are secure and robust.

This book is intended to be the primary reference for developers wishing to build secure APIs, and for security teams wanting to get a grip on the unique challenges of securing APIs. The book has a strong practical focus, with extensive code samples and tooling and references to real-world API breaches. The first part covers the basics of APIs and security, including common API vulnerabilities.

As a defender, it is essential to understand the methods of your adversaries, and I will guide you through the common skills and techniques employed by attackers. This will equip you with the skills to thoroughly test your APIs for common API weaknesses and vulnerabilities. The book addresses the full spectrum of API security, from pre-emptive secure-by-design practices as part of a shift-left approach to state-of-the-art runtime protection as part of a shield-right approach.

Finally, I draw on my experience of building large-scale software security programs to provide you with insights and strategies to establish and then mature your own API security programs.

Join me on this exciting journey into the world of API security and ensure that your APIs are never a point of weakness for attackers.

Who this book is for

This book is a perfect companion for security professionals responsible for API security. For AppSec teams, there is a focus on security tooling and integration and guidance on how to build an AppSec program targeting API security. For SecOps teams, there is in-depth coverage of API protection and monitoring to protect APIs at runtime.

The book is intended to be a reference for API developers, helping them understand the threats and attacks their APIs are likely to face and how to defend against the most common attack types, with a focus on API design first to enable shift-left for API security.

Finally, the book will appeal to system architects needing to understand best practices for secure API design and implementation.

What this book covers

Chapter 1, What Is API Security?, provides an introduction to the topic of API security and why it is important and distinct from web application security. This chapter also provides an understanding of the basics of APIs and their data formats, covering the key elements of API security and goals.

Chapter 2, Understanding APIs, covers the fundamentals of the HTTP protocol and the different types of APIs currently in use. The key topics of authentication and authorization are covered, along with the use of tokens and keys.

Chapter 3, Understanding Common API Vulnerabilities, provides in-depth coverage of the OWASP API Security Top 10 vulnerabilities (both the 2019 and 2023 variants), how vulnerabilities differ from abuse cases, and how APIs can expose business logic vulnerabilities.

Chapter 4, Investigating Recent Breaches, is an eye-opening look at some of the most significant API security breaches in the last few years, where we examine what went wrong and how such vulnerabilities could be prevented in the future.

Chapter 5, Foundations of Attacking APIs, provides a foundation of how adversaries attack APIs, including their methods, the common tools, and the skills they utilize.

Chapter 6, Discovering APIs, illuminates the various passive and active methods used by adversaries to discover APIs. We will also examine reconnaissance methods used to understand implementations and to evade common defense methods.

Chapter 7, Attacking APIs, provides hands-on guidance on how to attack APIs, focusing on the following areas – authentication and authorization attacks, data-based attacks, injection attacks, and other common attack types.

Chapter 8, Shift-Left for API Security, focuses on core activities that can be used to shift API security left, including leveraging the OpenAPI specification and the positive security model, how to threat model APIs, and the automation of API security within CI/CD pipelines.

Chapter 9, Defending against Common Vulnerabilities, covers the core topics of the defensive patterns and techniques that can be used to defend APIs against the following vulnerabilities – authentication and authorization vulnerabilities, data vulnerabilities, and implementation vulnerabilities.

Chapter 10, Securing Your Frameworks and Languages, moves the focus onto securing languages and frameworks using a “design-first” approach, including the use of code generation tooling, OpenAPI generation with popular frameworks, and patterns to secure these frameworks.

Chapter 11, Shield-Right for APIs with Runtime Protection, emphasizes the critical role played by so-called “shield-right” techniques, including secure and hardened environments, WAFs for API protection, the use of API gateways and management portals, API firewalls and, finally, monitoring APIs at runtime.

Chapter 12, Securing Microservices, looks at the exciting world of APIs within a microservices architecture, where we learn to apply our existing knowledge in a microservices landscape, focusing on securing the foundations, connectivity, and access control.

Chapter 13, Implementing an API Security Strategy, concludes our journey into API security by providing focused guidance on how to build an API security strategy, including the selection of a roadmap and KPIs, and how to plan and execute your strategy.

To get the most out of this book

The following are the software/hardware covered in the book and OS requirements:

Software/hardware covered in the book

Operating system requirements

Angular 9

Windows, macOS, or Linux

TypeScript 3.7

ECMAScript 11

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Defending-APIs. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “In this example, we can see that a combination of hellopixi and [email protected] resulted in a 200 OK status code and the return of a JWT.”

A block of code is set as follows:

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

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

{    "openapi": "3.0.0",   "info": {        "version": "1.0.0",        "title": "Swagger Petstore",        "license": {            "name": "MIT" }

Any command-line input or output is written as follows:

colind@mbm: ~ # sudo nmap -sn 192.168.9.0/24

Bold: Indicates a new term, an important word. For instance, words in menus or dialog boxes appear in bold. Here is an example: "YAML Ain’t Markup Language (YAML) is another common internet format, similar to JSON in its design goals".

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Defending APIs, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781804617120

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Foundations of API Security

In this part, you will gain a foundational understanding of the key components of Application Programming Interface (API) security. You will understand the need for a holistic approach to API security as APIs become the main target for hackers. We then take a look at the core building blocks of APIs, including protocols, data formats, authentication, authorization, and their role in security. The OWASP API Security Top 10 takes you on a walk-through of the most common vulnerabilities, and finally, this part concludes with detailed post-mortems of some of the highest-profile breaches in recent times.

This part has the following chapters:

Chapter 1, What Is API Security?Chapter 2, Understanding APIsChapter 3, Understanding Common API VulnerabilitiesChapter 4, Investigating Recent Breaches

1

What Is API Security?

A frequently quoted view is that there is no such thing as API 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 into API 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 relation to security.

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

The importance of API securityUnderstanding the basics of APIsAPI data formatsElements of API security and API security goals

Why API security is important

The Open Web Application Security Project (OWASP) published its first OWASP API Security Top 10 list in December 2019, and since then, the API 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 related to APIs.

In a way, APIs are a victim of their own success – because of their rapid proliferation and the high economic value of the data they protect, they are now the most popular target for 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 vector for 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 do the following:

Provide services and data to consumers for a priceConsume services and data from other providers to enhance your 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 the API 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 the Open 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 offers banking-as-a-service (BaaS) to third parties by renting out their APIs.

Advantages of an API economy

There are several key benefits to an API 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 development life cycles.Drive value: Organizations can expose new and innovative services using APIs and open new markets.Competitive advantage: By getting to market faster and using APIs to drive innovation, adopters can increase their competitive advantage.Improved efficiency: APIs allow IT teams to deliver immediate value by exposing APIs, rather than having to build and deploy mobile or web 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 focus given to the hardening and security of these APIs.

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

The scale of the API economy

It is difficult to 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. The API 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 some headline figures:

Over 90% of developers use APIsThe popular API test platform Postman has over 46 million API collections83% of all internet traffic belongs to APIsThere are over 2 million API GitHub repositoriesThe API management market is valued at $5.1 billion in 202393% of communication service providers use OpenAPI specifications91% of organizations have had an API security incident

On the back of a growing API economy, major capital investment has poured into the market for API tool vendors, management platforms, and security 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 cradle to 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 in more 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 between these services.

The benefit of APIs to developers are numerous, including the following:

They form an abstraction between services and allow encapsulation of functionality.They define a clear interface via an OpenAPI specification that serves as a contract for the API.They allow a truly polyglot environment where different APIs can be implemented in the most suitable programming language for the task at 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 the OpenAPI 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 API frameworks exist for most modern programming languages.

These factors have fueled the API-first paradigm where applications are built in a bottom-up approach, starting with the APIs, then the business logic, and the user 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 vulnerability being disclosed.

There are several key reasons why APIs are a favored attack 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 attack by adversaries.APIs are often well documented: To aid easy adoption and integration, good APIs should be documented using tools such as the Swagger UI. Unfortunately, such documentation can also be invaluable to attackers in understanding how the APIs work.API attacks can be automated: API interaction is headless (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 or web 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 a well-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 existing application security (AppSec) tooling that exists was designed in an era when web applications were the primary asset to be protected. Common security tools such as static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) are far less effective in assessing APIs than they are with web or mobile applications.

Traditional perimeter protections such as network firewalls or web 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 and false negatives.

More modern API technologies, such as API 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 all attack 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 of this 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 address the problem.

Developers are, by nature, creative problem solvers who thrive on a challenge – unfortunately, this leads them to be over-optimistic, which can lead them to take shortcuts and optimizations, or perhaps work to unrealistic delivery schedules. This is so-called happy path coding, where developers do not fully appreciate how their code could fail or be misused by an attacker, sometimes with dire consequences.

Coupled with over-optimism is a sense of over-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 a vulnerable 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 the schadenfreude 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 an incomplete state.

Often, developers inherit a code base to maintain that may contain significant technical 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 they break functionality.

Exploring API building blocks

Before we can understand how 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 grasp these basics.

Rate limiting

Public APIs are exposed to the internet and can easily be discovered by adversaries. One of the simplest attacks against an API is a denial-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 to the API.

Brute-force attacks can also be used in account takeover (ATO) attacks, where either a sign-up endpoint or a password reset endpoint are flooded in attempts to guess passwords or hashes, using a dictionary attack (where a list of commonly used passwords is 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 a 429 Too Many Requests error.

Cryptography

Cryptography is a foundational element in securing data electronically – most simply, it is a mathematical transformation applied to data. Typically, cleartext (unencrypted) is transformed into cyphertext (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 and the key.

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

Symmetric algorithm: In this type, the same key is used to encrypt and decrypt data. The benefit of symmetric 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 this type, 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) of keys between 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 most used protocol.

Cryptography provides the following benefits:

Authentication: By using public-key cryptography, it is possible to verify the identity of the originating party by using their public key to confirm they signed a message with their private key, which only they can access. By using certificates, it is possible to verify the validity (or trust) associated with public keys – this is the foundation of Transport Layer Security (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 or document 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 access the data.Integrity: Finally, cryptography can be used to ensure the integrity of data, verifying that it has not been modified in transit. By transmitting a fingerprint of 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 validating it against the one received.

Hashes, HMACs, and signatures

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

Hashes are the most elementary technique, in which a block of data is passed through an algorithm to produce a digest of 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 are one-way functions or 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 integrity of data.

Hashed Authentication Message Codes (HMACs) are similar 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 their shared key).

Signatures are 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 and verify the integrity. Using robust principles of public key infrastructure (PKI), public keys can be trusted (their ownership can be verified).

The following table summarizes the differences between the three types:

Objective

Hash

HMAC

Signature

Integrity

Authenticity

Non-repudiation

Table 1.1 – A comparison of digest types

Transport security

The TLS protocol is a transport-level cryptographic protocol to ensure secure communications over a TCP/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 a lot simpler.

Encoding

The final building block is that of encoding, which involves 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 its original format.

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

HTML encoding: In HTML, certain characters have special significance – for example, < and >. If a text block contains these characters, it will change the structure of the rendered HTML, which is undesirable. By encoding these special characters in another format ("&lt;" and "&gt;"), they can be safely rendered in an HTML document, where they will be displayed correctly as < and > but stored in a different form.URL encoding: Similarly, in a URL, only the ASCII character set is allowed; all other characters are forbidden. 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 converted to %20.ASCII, UTF8, and Unicode: Text can be represented in a number of different formats and can be converted from one to the other, depending on the platforms and locales in use.Base64: This is a commonly used encoder to transform binary data to text data suitable for transmission over 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 same original content.

Encoding versus encryption

A common misunderstanding is the difference between encoding and encryption. They are two very different topics, solving different 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 or confidentiality functions.

Encryption performs 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 of the data.

Examining API data formats

Finally, in this section, let’s take 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 optional response 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 course extensible, not being reliant on any strict schema definition (unlike HTML, which uses fixed tags and 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 so in APIs.

A simple example of XML shows the basic structure of tags and 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 transfer format 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 and client-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 in JSON data.

A simple example of JSON shows the key-value pair structure:

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

YAML

YAML Ain’t Markup Language (YAML) is another 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 for OpenAPI definitions.

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

--- name: Colin age: 52 car:

OpenAPI Specification

The final format we need to understand is the OpenAPI 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 time of writing.

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

Figure 1.1 – OpenAPI Specification sections

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

Description validation and linting: Parsers and audit tools can automatically validate a definition to confirm its correctness and completeness.Data validation: Request and response data can be fully specified, allowing validation of API behavior at runtime.Documentation generation: Documentation can be automatically generated from a definition, including a test UI, allowing the API to be exercised.Code generation: Tools exist that allow the server and client code stubs to be generated in a variety of languages, easing the burden on 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 development and 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 excessive information exposure.

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

The OpenAPI versionInformation metadataServer information, including the host 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 the OAS definition describes an endpoint, showing details such as the following:

The endpoint path nameThe HTTP method to be usedRequest parametersStatus codesThe response 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 of API security.

Understanding the elements of API 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 may prove challenging.

Good security is built on a multi-layer system – this is the defense in-depth approach.

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 specific to APIs.

The elements of the API security hierarchy are shown here:

Figure 1.2: The elements of API security

Let’s explore each of the layers of API security briefly.

DevOps

DevOps is a well-established set 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 the Software Development Lifecycle (SDLC), as shown here:

Figure 1.3: The DevOps cycle

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

Improved collaboration and trustFaster release cyclesReduced time to repairHigher levels of automationUse of standard processes, including testing and 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 standard Continuous 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 for this activity.

SAST, DAST, SCA, and WAFs

Static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), and web application firewalls (WAFs) form the vanguard of traditional application security 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 time of developmentDAST can detect application vulnerabilities at runtimeSCA can detect the use of vulnerable components and librariesWAFs can afford some level of protection against certain attack 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 requests and 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-called allow list to block suspected malicious traffic and allowing everything else. They can be configured to operate in monitor mode (passive) or blocking mode (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 with these 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-level controls such as SSL termination, rate-limiting, IP address restrictions, and load balancing. Gateways can also implement security features such as JWT validation and identity management.

Some of the shortcomings of API gateways include the following:

API gateways provide a central point of entry for API traffic and are effective at acting as a gatekeeper at the front door of the customer infrastructure; however, they are less effective at protecting what goes on behind the doorGateways are ineffective at protecting against several of the OWASP API Security Top 10 vulnerabilitiesGateways can be inefficient at providing security processing functions such as traffic inspection

Typically, API management portals 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 providing API catalogs.

Some of the shortcomings of API management platforms include the following:

APIM portals are effective for providing a central view of an API inventory and also a single point of deployment for API policyEffective APIM deployment is contingent on development teams embracing a design-first approach and enrolling their APIs into a central 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 the overall 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 a first-class citizen.

These platforms take different perspectives of securing APIs, including the following:

Continuous monitoring of API traffic to detect emergent threats using machine learning (ML) and artificial intelligence (AI) technologyDedicated API firewalls that can protect APIs by enforcing the OpenAPI contract – this is the positive security model covered in the next sectionScanning APIs to validate the API behavior against an OpenAPI contractProviding audit tools to ensure OpenAPI contracts adhere to best practices for data and 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 API security goals.

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 endpointsScrapers 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 APIsNuisance 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