Book Image

Defending APIs

By : Colin Domoney
Book Image

Defending APIs

By: Colin Domoney

Overview of this book

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.
Table of Contents (19 chapters)
1
Part 1: Foundations of API Security
6
Part 2: Attacking APIs
10
Part 3: Defending APIs

Using API gateways and API management

We now focus on the core shield right technology for APIs, namely API gateways and API management (APIM) solutions. To understand what an API gateway does, let us consider how APIs were deployed before gateways existed. Typically, an API would be instantiated on a server, assigned a resolvable name, and connected to the public internet. While this achieved the result of bringing the API online, it created a myriad of other problems for system administrators:

  • Difficulty in scaling the service, either horizontally or vertically
  • A very tightly coupled architecture – the internal architecture of the system was exposed directly to the client and could not be refactored without potentially breaking all clients
  • The lack of a common approach to cross-cutting concerns (issues common to all APIs best addressed in a standard method) meant that each API had to implement its own logging, access control, rate limiting, and load balancing...