Hacking APIs [Corey J Ball] (pdf) читать онлайн

PRAISE FOR
HACKING APIS
“Corey Ball’s Hacking APIs delivers exactly what it promises. From basic definitions, through the theory behind common API weaknesses and hacking best
practices, the reader is encouraged to take a truly adversarial mindset. This
highly effective, hands-on journey starts with tool introduction and reconnaissance, then covers everything from API fuzzing to complex access-control
exploitation. With detailed labs, tips and tricks, and real-life examples, Hacking
APIs is a complete workshop rolled into one book.”
—Erez Yalon, VP of security research
at Checkmarx and OWASP API
­security project leader
“Author Corey Ball takes you on a lively guided tour through the life cycle of
APIs in such a manner that you’re wanting to not only know more, but also
anticipating trying out your newfound knowledge on the next legitimate
target. From concepts to examples, through to identifying tools and demonstrating them in fine detail, this book has it all. It is the mother lode for API
hacking, and should be found next to the desk of ANYONE wanting to take
this level of adversarial research, assessment, or DevSecOps seriously.”
—Chris Roberts, strategic adviser at
Ethopass, international vCISO
“Hacking APIs is extremely helpful for anyone who wants to get into penetration
testing. In particular, this book gives you the tools to start testing the security
of APIs, which have become a weak point for many modern web applications.
Experienced security folks can get something out of the book, too, as it features lots of helpful automation tips and protection-bypass techniques that
will surely up any pentester’s game.”
—Vickie Li, author of Bug Bounty Bootcamp
“This book opens the doors to the field of API hacking, a subject not very well
understood. Using real-world examples that emphasize vital access-control
issues, this hands-on tutorial will help you understand the ins and outs of
securing APIs, how to hunt great bounties, and will help organizations of all
sizes improve their overall API security.”
—Inon Shkedy, security researcher at
Traceable AI and OWASP API security
project leader
“Even though the internet is filled with information on any topic possible in
cybersecurity, it is still hard to find solid insight into successfully performing
penetration tests on APIs. Hacking APIs fully satisfies this demand—not only
for the beginner cybersecurity practitioner, but also for the seasoned expert.”
—Cristi Vlad, cybersecurity analyst
and penetration tester

HACKING APIS
B r e a k i n g We b A p p l i c a t i o n
Programming Interfaces

b y Cor e y J . B a ll

San Francisco

HACKING APIS. Copyright © 2022 by Corey Ball.
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage or retrieval
system, without the prior written permission of the copyright owner and the publisher.
First printing
26 25 24 23 22

12345

ISBN-13: 978-1-7185-0244-4 (print)
ISBN-13: 978-1-7185-0245-1 (ebook)
Publisher: William Pollock
Managing Editor: Jill Franklin
Production Manager: Rachel Monaghan
Production Editor: Jennifer Kepler
Developmental Editor: Frances Saux
Cover Illustrator: Gina Redman
Interior Design: Octopod Studios
Technical Reviewer: Alex Rifman
Copyeditor: Bart Reed
Compositor: Maureen Forys, Happenstance Type-O-Rama
Proofreader: Paula L. Fleming
For information on distribution, bulk sales, corporate sales, or translations, please contact No Starch
Press, Inc. directly at info@nostarch.com or:
No Starch Press, Inc.
245 8th Street, San Francisco, CA 94103
phone: 1.415.863.9900
www.nostarch.com
Library of Congress Cataloging-in-Publication Data
Names: Ball, Corey (Cybersecurity manager), author.
Title: Hacking APIs : breaking web application programming interfaces / by
Corey Ball.
Description: San Francisco : No Starch Press, [2022] | Includes index.
Identifiers: LCCN 2021061101 (print) | LCCN 2021061102 (ebook) | ISBN
9781718502444 (paperback) | ISBN 9781718502451 (ebook)
Subjects: LCSH: Application program interfaces (Computer software) |
Application software--Development.
Classification: LCC QA76.76.A63 B35 2022 (print) | LCC QA76.76.A63
(ebook) | DDC 005.8--dc23/eng/20220112
LC record available at https://lccn.loc.gov/2021061101
LC ebook record available at https://lccn.loc.gov/2021061102

No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other
product and company names mentioned herein may be the trademarks of their respective owners. Rather
than use a trademark symbol with every occurrence of a trademarked name, we are using the names only
in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of
the trademark.
The information in this book is distributed on an “As Is” basis, without warranty. While every precaution
has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any
liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly
or indirectly by the information contained in it.

To my incredible wife, Kristin, and our three
amazing daughters, Vivian, Charlise, and Ruby.
Your distractions were almost always a delight, and
they probably only cost the world a data breach or two.
You are the light of my life, and I love you.

About the Author
Corey Ball is a cybersecurity consulting manager at Moss Adams, where he
leads penetration testing services. He has over 10 years of experience working in IT and cybersecurity across several industries, including aerospace,
agribusiness, energy, fintech, government services, and health care. In addition to bachelor’s degrees in both English and philosophy from Sacramento
State University, he holds the OSCP, CCISO, CEH, CISA, CISM, CRISC,
and CGEIT industry certifications.

About the Technical Reviewer
Alex Rifman is a security industry veteran with a background in defense
strategies, incident response and mitigation, threat intelligence, and risk
management. He currently serves as a head of customer success at APIsec,
an API security company, where he works with customers to ensure their
APIs are secure.

BRIEF CONTENTS

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

PART I: HOW WEB API SECURITY WORKS . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 0: Preparing for Your Security Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 1: How Web Applications Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2: The Anatomy of Web APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3: Common API Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

PART II: BUILDING AN API TESTING LAB . . . . . . . . . . . . . . . . . . . . . . . . 69
Chapter 4: Your API Hacking System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 5: Setting Up Vulnerable API Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

PART III: ATTACKING APIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Chapter 6: Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chapter 7: Endpoint Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Chapter 8: Attacking Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Chapter 9: Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Chapter 10: Exploiting Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Chapter 11: Mass Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Chapter 12: Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

PART IV: REAL-WORLD API HACKING . . . . . . . . . . . . . . . . . . . . . . . . . 265
Chapter 13: Applying Evasive Techniques and Rate Limit Testing . . . . . . . . . . . . . . . . . . . . 267
Chapter 14: Attacking GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Chapter 15: Data Breaches and Bug Bounties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Appendix A: API Hacking Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Appendix B: Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

viii

Brief Contents

CO N T E N T S I N D E TA I L

FOREWORD

xvii

ACKNOWLEDGMENTS

xxi

INTRODUCTION

xxiii

The Allure of Hacking Web APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
This Book’s Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Hacking the API Restaurant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

PART I: HOW WEB API SECURITY WORKS

1

0
PREPARING FOR YOUR SECURITY TESTS

3

Receiving Authorization . . . . . . . . . . .
Threat Modeling an API Test . . . . . . . .
Which API Features You Should Test . .
API Authenticated Testing . . .
Web Application Firewalls . .
Mobile Application Testing . .
Auditing API Documentation .
Rate Limit Testing . . . . . . . . .
Restrictions and Exclusions . . . . . . . . .
Security Testing Cloud APIs . .
DoS Testing . . . . . . . . . . . . .
Reporting and Remediation Testing . . .
A Note on Bug Bounty Scope . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

1
HOW WEB APPLICATIONS WORK
Web App Basics . . . . . . . . . . . . . . .
The URL . . . . . . . . . . . . . .
HTTP Requests . . . . . . . . . .
HTTP Responses . . . . . . . . .
HTTP Status Codes . . . . . . .
HTTP Methods . . . . . . . . . .
Stateful and Stateless HTTP .
Web Server Databases . . . . . . . . . .
SQL . . . . . . . . . . . . . . . . .
NoSQL . . . . . . . . . . . . . . .
How APIs Fit into the Picture . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

. 4
. 4
. 6
. 6
. 7
. 7
. 8
. 8
. 9
10
10
11
11
13

15
15
16
17
18
19
20
22
23
23
24
25
26

2
THE ANATOMY OF WEB APIS
How Web APIs Work . . . . . . . . . . . .
Standard Web API Types . . . . . . . . . .
RESTful APIs . . . . . . . . . . . .
GraphQL . . . . . . . . . . . . . .
REST API Specifications . . . . . . . . . . .
API Data Interchange Formats . . . . . . .
JSON . . . . . . . . . . . . . . . . .
XML . . . . . . . . . . . . . . . . . .
YAML . . . . . . . . . . . . . . . . .
API Authentication . . . . . . . . . . . . . . .
Basic Authentication . . . . . . .
API Keys . . . . . . . . . . . . . . .
JSON Web Tokens . . . . . . . .
HMAC . . . . . . . . . . . . . . . .
OAuth 2.0 . . . . . . . . . . . . .
No Authentication . . . . . . . .
APIs in Action: Exploring Twitter’s API .
Summary . . . . . . . . . . . . . . . . . . . . .

27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

3
COMMON API VULNERABILITIES
Information Disclosure . . . . . . . . . . .
Broken Object Level Authorization . . .
Broken User Authentication . . . . . . .
Excessive Data Exposure . . . . . . . . .
Lack of Resources and Rate Limiting . .
Broken Function Level Authorization .
Mass Assignment . . . . . . . . . . . . . .
Security Misconfigurations . . . . . . . .
Injections . . . . . . . . . . . . . . . . . . . .
Improper Assets Management . . . . . .
Business Logic Vulnerabilities . . . . . .
Summary . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

53
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

PART II: BUILDING AN API TESTING LAB

.
.
.
.
.
.
.
.
.
.
.
.

Kali Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Web Apps with DevTools . . . . . . . . . . .
Capturing and Modifying Requests with Burp Suite .
Setting Up FoxyProxy . . . . . . . . . . . . . . .
Adding the Burp Suite Certificate . . . . . . .
Navigating Burp Suite . . . . . . . . . . . . . .
Intercepting Traffic . . . . . . . . . . . . . . . . .
Altering Requests with Intruder . . . . . . . . .

Contents in Detail

54
55
56
58
59
59
61
62
64
65
66
67

69

4
YOUR API HACKING SYSTEM

x

28
30
30
34
38
39
39
41
42
42
43
44
45
46
47
48
48
51

71
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

72
72
75
76
76
77
79
81

Crafting API Requests in Postman, an API Browser . . . . . . .
The Request Builder . . . . . . . . . . . . . . . . . . . . .
Environments . . . . . . . . . . . . . . . . . . . . . . . . . .
Collections . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Collection Runner . . . . . . . . . . . . . . . . . . . .
Code Snippets . . . . . . . . . . . . . . . . . . . . . . . . .
The Tests Panel . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Postman to Work with Burp Suite . . . . . . . . . .
Supplemental Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Reconnaissance with OWASP Amass .
Discovering API Endpoints with Kiterunner . . . . . .
Scanning for Vulnerabilities with Nikto . . . . . . . .
Scanning for Vulnerabilities with OWASP ZAP . . .
Fuzzing with Wfuzz . . . . . . . . . . . . . . . . . . . . .
Discovering HTTP Parameters with Arjun . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

. 84
. 86
. 89
. 90
. 93
. 94
. 94
. 95
. 96
. 97
. 98
. 99
100
100
102
103

Lab #1: Enumerating the User Accounts in a REST API . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5
SETTING UP VULNERABLE API TARGETS
Creating a Linux Host . . . . . . . . . . . . . . . . . . . .
Installing Docker and Docker Compose . . . . . . . .
Installing Vulnerable Applications . . . . . . . . . . . .
The completely ridiculous API (crAPI) . . .
OWASP DevSlop’s Pixi . . . . . . . . . . . . .
OWASP Juice Shop . . . . . . . . . . . . . . .
Damn Vulnerable GraphQL Application .
Adding Other Vulnerable Apps . . . . . . . . . . . . . .
Hacking APIs on TryHackMe and HackTheBox . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

109
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

110
110
111
111
112
112
113
114
115
116

Lab #2: Finding Your Vulnerable APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

PART III: ATTACKING APIS

121

6
DISCOVERY
Passive Recon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Passive Recon Process . . . . . . . . . . . . . . . . . . .
Google Hacking . . . . . . . . . . . . . . . . . . . . . . . . .
ProgrammableWeb’s API Search Directory . . . . . . .
Shodan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OWASP Amass . . . . . . . . . . . . . . . . . . . . . . . . . .
Exposed Information on GitHub . . . . . . . . . . . . . . .
Active Recon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Active Recon Process . . . . . . . . . . . . . . . . . . .
Baseline Scanning with Nmap . . . . . . . . . . . . . . . .
Finding Hidden Paths in Robots.txt . . . . . . . . . . . . .
Finding Sensitive Information with Chrome DevTools .
Validating APIs with Burp Suite . . . . . . . . . . . . . . .

123
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

124
124
125
127
129
131
133
136
136
138
139
139
142
Contents in Detail

xi

Crawling URIs with OWASP ZAP . . . . . .
Brute-Forcing URIs with Gobuster . . . . . .
Discovering API Content with Kiterunner .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

143
145
146
148

Lab #3: Performing Active Recon for a Black Box Test . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7
ENDPOINT ANALYSIS
Finding Request Information . . . . . . . . . . . . . . . . . .
Finding Information in Documentation . . . . .
Importing API Specifications . . . . . . . . . . .
Reverse Engineering APIs . . . . . . . . . . . . .
Adding API Authentication Requirements to Postman .
Analyzing Functionality . . . . . . . . . . . . . . . . . . . . .
Testing Intended Use . . . . . . . . . . . . . . . . .
Performing Privileged Actions . . . . . . . . . .
Analyzing API Responses . . . . . . . . . . . . .
Finding Information Disclosures . . . . . . . . . . . . . . . .
Finding Security Misconfigurations . . . . . . . . . . . . .
Verbose Errors . . . . . . . . . . . . . . . . . . . . .
Poor Transit Encryption . . . . . . . . . . . . . . .
Problematic Configurations . . . . . . . . . . . .
Finding Excessive Data Exposures . . . . . . . . . . . . . .
Finding Business Logic Flaws . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

156
156
159
161
164
166
167
168
169
169
170
170
171
171
172
173
174

Lab #4: Building a crAPI Collection and Discovering Excessive Data Exposure . . . . . . . . 174

8
ATTACKING AUTHENTICATION
Classic Authentication Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Password Brute-Force Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .
Password Reset and Multifactor Authentication Brute-Force Attacks .
Password Spraying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Including Base64 Authentication in Brute-Force Attacks . . . . . . . . .
Forging Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manual Load Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Live Token Capture Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .
Brute-Forcing Predictable Tokens . . . . . . . . . . . . . . . . . . . . . . . .
JSON Web Token Abuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recognizing and Analyzing JWTs . . . . . . . . . . . . . . . . . . . . . . .
The None Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Algorithm Switch Attack . . . . . . . . . . . . . . . . . . . . . . . . . . .
The JWT Crack Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

180
180
181
183
185
187
187
189
190
192
193
195
195
196
197

Lab #5: Cracking a crAPI JWT Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

xii

Contents in Detail

9
FUZZING

201

Effective Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Choosing Fuzzing Payloads . . . . . . . . . . . . . .
Detecting Anomalies . . . . . . . . . . . . . . . . . . . . .
Fuzzing Wide and Deep . . . . . . . . . . . . . . . . . . . . . . . .
Fuzzing Wide with Postman . . . . . . . . . . . . . . .
Fuzzing Deep with Burp Suite . . . . . . . . . . . . . .
Fuzzing Deep with Wfuzz . . . . . . . . . . . . . . . . .
Fuzzing Wide for Improper Assets Management .
Testing Request Methods with Wfuzz . . . . . . . . . . . . . . . .
Fuzzing “Deeper” to Bypass Input Sanitization . . . . . . . . .
Fuzzing for Directory Traversal . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

202
203
204
207
207
210
212
214
216
217
218
218

Lab #6: Fuzzing for Improper Assets Management Vulnerabilities . . . . . . . . . . . . . . . . . 219

10
EXPLOITING AUTHORIZATION
Finding BOLAs . . . . . . . . . . . . . . . . . .
Locating Resource IDs . . . . . . .
A-B Testing for BOLA . . . . . . .
Side-Channel BOLA . . . . . . . .
Finding BFLAs . . . . . . . . . . . . . . . . . . .
A-B-A Testing for BFLA . . . . . . .
Testing for BFLA in Postman . . .
Authorization Hacking Tips . . . . . . . . .
Postman’s Collection Variables .
Burp Suite Match and Replace .
Summary . . . . . . . . . . . . . . . . . . . . . .

223
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

223
224
225
226
227
227
228
230
230
231
231

Lab #7: Finding Another User’s Vehicle Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

11
MASS ASSIGNMENT
Finding Mass Assignment Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Account Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unauthorized Access to Organizations . . . . . . . . . . . . . . . . . .
Finding Mass Assignment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . .
Finding Variables in Documentation . . . . . . . . . . . . . . . . . . . .
Fuzzing Unknown Variables . . . . . . . . . . . . . . . . . . . . . . . . .
Blind Mass Assignment Attacks . . . . . . . . . . . . . . . . . . . . . . .
Automating Mass Assignment Attacks with Arjun and Burp Suite Intruder .
Combining BFLA and Mass Assignment . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

237
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

238
238
238
239
239
240
241
241
242
243

Lab #8: Changing the Price of Items in an Online Store . . . . . . . . . . . . . . . . . . . . . . . . . 243

Contents in Detail

xiii

12
INJECTION

249

Discovering Injection Vulnerabilities . . . . . . . . .
Cross-Site Scripting (XSS) . . . . . . . . . . . . . . . .
Cross-API Scripting (XAS) . . . . . . . . . . . . . . . .
SQL Injection . . . . . . . . . . . . . . . . . . . . . . . .
Manually Submitting Metacharacters .
SQLmap . . . . . . . . . . . . . . . . . . . . .
NoSQL Injection . . . . . . . . . . . . . . . . . . . . . .
Operating System Command Injection . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

250
251
252
253
255
256
257
259
261

Lab #9: Faking Coupons Using NoSQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

PART IV: REAL-WORLD API HACKING

265

13
APPLYING EVASIVE TECHNIQUES AND RATE LIMIT TESTING
Evading API Security Controls . . . . . . . . . . . .
How Security Controls Work . . . . . .
API Security Control Detection . . . . .
Using Burner Accounts . . . . . . . . . .
Evasive Techniques . . . . . . . . . . . . .
Automating Evasion with Burp Suite .
Automating Evasion with Wfuzz . . .
Testing Rate Limits . . . . . . . . . . . . . . . . . . . .
A Note on Lax Rate Limits . . . . . . . .
Path Bypass . . . . . . . . . . . . . . . . . .
Origin Header Spoofing . . . . . . . . .
Rotating IP Addresses in Burp Suite .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

267
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

14
ATTACKING GRAPHQL
GraphQL Requests and IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Active Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing DVGA in a Browser . . . . . . . . . . . . . . . . . . . . . . . . .
Using DevTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Engineering the GraphQL API . . . . . . . . . . . . . . . . . . . . . . . . .
Directory Brute-Forcing for the GraphQL Endpoint . . . . . . . . . .
Cookie Tampering to Enable the GraphiQL IDE . . . . . . . . . . . .
Reverse Engineering the GraphQL Requests . . . . . . . . . . . . . . .
Reverse Engineering a GraphQL Collection Using Introspection .
GraphQL API Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crafting Requests Using the GraphiQL Documentation Explorer .
Using the InQL Burp Extension . . . . . . . . . . . . . . . . . . . . . . . .
Fuzzing for Command Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiv

Contents in Detail

267
268
269
270
270
273
274
276
276
278
279
280
284

285
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

286
287
287
288
289
290
290
292
294
296
297
297
298
301
305

15
DATA BREACHES AND BUG BOUNTIES
The Breaches . . . . . . . . . . . . . . . . . . . . . . . . . .
Peloton . . . . . . . . . . . . . . . . . . . . . . . .
USPS Informed Visibility API . . . . . . . . .
T-Mobile API Breach . . . . . . . . . . . . . . .
The Bounties . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Price of Good API Keys . . . . . . . . . .
Private API Authorization Issues . . . . . . .
Starbucks: The Breach That Never Was .
An Instagram GraphQL BOLA . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

307
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

308
308
309
311
312
312
313
315
317
318

CONCLUSION

319

A
API HACKING CHECKLIST

321

B
ADDITIONAL RESOURCES

323

INDEX

327

Contents in Detail

xv

FORE WORD

Imagine if sending money to a friend required more
than opening an app and making a few clicks. Or if
monitoring your daily steps, exercise data, and nutrition information meant checking three separate applications. Or if comparing airfares involved manually
visiting each airline’s website.
Of course, it’s not hard to imagine this world: we lived in it not too long
ago. But APIs have changed all that. They are the glue that has enabled collaboration across companies and transformed how enterprises build and
run applications. Indeed, APIs have become so pervasive that an Akamai
report from October 2018 found that API calls accounted for an astounding
83 percent of all web traffic.
But as with most things on the internet, if there’s something good,
cybercriminals will take notice. To these criminals, APIs are highly fertile
and profitable ground, and for good reason. These services offer two highly
desirable traits: (1) rich sources of sensitive information and (2) frequent
security gaps.

Consider the role APIs play in a typical application architecture. When
you check your bank balance on a mobile app, an API behind the scenes
requests that information and sends it to the app. Likewise, when you apply
for a loan, an API allows the bank to request your credit history. APIs sit in a
critical position between users and the sensitive systems on the backend. If
a cybercriminal can compromise the API layer, they could get direct access
to highly valuable information.
While APIs have reached an unprecedented level of adoption, their
security continues to lag. I recently spoke with the chief information
security officer of a 100-year-old energy company and was surprised
to learn they use APIs throughout the organization. But, he quickly
pointed out, “whenever we look under the hood, we find they are often
over-permissioned.”
This isn’t very surprising. Developers live under constant pressure to
fix bugs, push new releases to consumers, and add functionality to their
services. Rather than scheduling releases every few months, they must cycle
through nightly builds and daily commits. There literally isn’t enough time
to consider the security implications of every change they make, and so
undiscovered vulnerabilities weasel their way into products.
Unfortunately, lax API security practices too often result in unexpected
outcomes. Take the US Postal Service (USPS). The agency published an
API called Informed Visibility that allowed organizations and users to track
packages. Appropriately, the API required users to validate their identity
and authenticate in order to access any information via the API. However,
once authenticated, a user could look up the account information of any
other user, exposing the information of 60 million users.
Peloton, the fitness company, also powers its apps (and even its equipment) with APIs. But because one of its APIs required no authentication
to issue a call and get responses from the Peloton server, it allowed the
requester to look up the account information of any other Peloton device
(of which there are four million) and access potentially sensitive user information. Even US president Joe Biden, a well-known Peloton user, had his
information exposed by this unsecured endpoint.
Here’s a third example: the electronic payment firm Venmo relies on
APIs to power its applications and connect to financial institutions. One of
its APIs served a marketing function by showing recent, anonymized transactions. While user interfaces took care of stripping out any sensitive information, the API would return all transaction details when called directly.
Malicious users harvested some 200 million transactions via this API.
Incidents like these have become so commonplace that the analyst
firm Gartner has predicted that API breaches will become the “most frequent attack vector” by 2022, and IBM has reported that two-thirds of
cloud breaches are the result of API misconfigurations. The breaches also
highlight the need for new approaches to securing APIs. The application
security solutions of the past focus only on the most common attack types
and vulnerabilities. For example, automated scanners search the Common
Vulnerabilities and Exposures (CVE) database for flaws in IT systems, and
web application firewalls monitor traffic in real time to blockmalicious
xviii

Foreword

requests containing known flaws. These tools are well suited to detecting
traditional threats, but they fail to address the core security challenges
faced by APIs.
The problem is that API vulnerabilities are not common. Not only do
they vary highly from one API to another, but they also tend to differ from
those found in traditional applications. The breach at USPS wasn’t a security
misconfiguration; it was a business logic flaw. That is, the application logic
contained an unintended loophole that permitted an authenticated, valid
user to access data belonging to another user. This type of flaw, known as
broken object level authorization, is the result of application logic that fails
to control what an authorized user is able to access.
Put more succinctly, these unique API logic flaws are effectively zeroday vulnerabilities, each of which belongs only to a specific API. Because
of the scope of these threats, a book like this one is crucial to educating
penetration testers and bug bounty hunters interested in keeping APIs
secure. Additionally, as security shifts “left” to the engineering and development processes, API security is no longer strictly the domain of companies’
information security departments. This book can be a guide to any modern
engineering team that conducts security testing alongside functional and
unit testing.
When done properly, API security testing programs are continuous and
comprehensive. Tests conducted once or twice a year won’t keep up with the
pace of new releases. Instead, testing should become part of the development cycle, such that every release gets vetted before moving to production,
and cover the API’s entire footprint. Finding API vulnerabilities takes new
skills, new tools, and new approaches. The world needs Hacking APIs now
more than ever.
Dan Barahona
Chief Strategy Officer, APIsec.ai Inc.
San Francisco, CA

Foreword

xix

ACKNOW LEDGMENT S

Before we begin, I must thank and acknowledge some giants whose shoulders I have stood on for the creation of this book:
My family and friends for supporting me in all my endeavors.
Kevin Villanueva for volunteering me to lead the API penetration testing efforts at Moss Adams in 2019. Troy Hawes, Francis Tam, and everyone
else on the Moss Adams Cybersecurity team for challenging, helping, and
provoking me to be better.
Gary Lamb, Eric Wilson, and Scott Gnile for being a such great mentors
in my career.
Dan Barahona for writing the foreword and providing constant support. Also, the rest of the APIsec.ai team for their API security articles,
webinars, and their awesome API security testing platform.
Alex Rifman for providing top-notch technical editing and jumping
into the project at a speed that would have impressed Barry Allen.
Inon Shkedy for his support throughout the writing of this book and
providing me with beta access to crAPI. Additional thanks to the rest of the
OWASP API Security Top 10 project team, Erez Yalon and Paulo Silva.
Tyler Reynolds and the team at Traceable.ai for their constant support,
content, and diligence to secure all the APIs.
Ross E. Chapman, Matt Atkinson, and the PortSwigger team for not
only providing one of the best API hacking suites out there but also for giving me the opportunity to evangelize API security.
Dafydd Stuttard and Marcus Pinto for their groundbreaking work on
the Web Application Hacker’s Handbook.
Dolev Farhi for Damn GraphQL, his excellent conference talks, and all
his help with the GraphQL sections of this book.
Georgia Weidman for her foundational work in Penetration Testing, without which I am not sure I’d be writing this book.
Ippsec, STÖK, InsiderPhD, and Farah Hawa for hosting impressive and
approachable hacking content.
Sean Yeoh and the rest of the great team at Assetnote for their API
hacking content and tools.
Fotios Chantzis, Vickie Li, and Jon Helmus for their guidance through
the realities of writing and releasing a cybersecurity book.

APIsecurity.io for providing the world some of the best API security
resources and news out there.
Omer Primor and the Imvision team for letting me review the latest
API security content and participate in webinars.
Chris Roberts and Chris Hadnagy for being constant sources of
inspiration.
Wim Hof for helping me keep and maintain my sanity.
And, of course, the excellent team at No Starch Press, including Bill
Pollock, Athabasca Witschi, and Frances Saux for taking the ramblings of
an API hacking madman and turning them into this book. Bill, thanks for
taking a chance on me at a time when the world was filled with so many
uncertainties. I am grateful.

xxii

Acknowledgments

INTRODUCTION

Today’s researchers estimate that application programming interface (API) calls
make up more than 80 percent of all web
traffic. Yet despite their prevalence, web application hackers often fail to test them. And these
vital business assets can be riddled with catastrophic
weaknesses.
As you’ll see in this book, APIs are an excellent attack vector. After all,
they’re designed to expose information to other applications. To compromise an organization’s most sensitive data, you may not need to cleverly
penetrate the perimeter of a network firewall, bypass an advanced antivirus,
and release a zero day; instead, your task could be as simple as making an
API request to the right endpoint.
The goal of this book is to introduce you to web APIs and show you
how to test them for a myriad of weaknesses. We’ll primarily focus on testing the security of REST APIs, the most common API format used in web

applications, but will cover attacking GraphQL APIs as well. You’ll first
learn tools and techniques for using APIs as intended. Next, you’ll probe
them for vulnerabilities and learn how to exploit those vulnerabilities. You
can then report your findings and help prevent the next data breach.

The Allure of Hacking Web APIs
In 2017, The Economist, one of the leading sources of information for international business, ran the following headline: “The world’s most valuable
resource is no longer oil, but data.” APIs are digital pipelines that allow a
precious commodity to flow across the world in the blink of an eye.
Simply put, an API is a technology that enables communication
between different applications. When, for example, a Python application
needs to interact with the functionality of a Java app, things can get messy
very quickly. By relying on APIs, developers can design modular applications that leverage the expertise of other applications. For example, they no
longer need to create their own custom software to implement maps, payment processors, machine-learning algorithms, or authentication processes.
As a result, many modern web applications have been quick to adopt
APIs. Yet new technologies often get quite a head start before cybersecurity
has a chance to ask any questions, and APIs have hugely expanded these
applications’ attack surfaces. They’ve been so poorly defended that attackers can use them as a direct route to their data. In addition, many APIs
lack the security controls that other attack vectors have in place, making
them the equivalent of the Death Star’s thermal exhaust port: a path to
doom and destruction for businesses.
Due to these reasons, Gartner predicted years ago that by 2022, APIs
will be the leading attack vector. As hackers, we need to secure them by
putting on our rollerblades, strapping the Acme rocket to our backs, and
catching up to the speed of technological innovation. By attacking APIs,
reporting our findings, and communicating risks to the business, we can do
our part to thwart cybercrime.

This Book’s Approach
Attacking APIs is not as challenging as you may think. Once you understand how they operate, hacking them is only a matter of issuing the right
HTTP requests. That said, the tools and techniques typically leveraged to
perform bug hunting and web application penetration testing do not translate well to APIs. You can’t, for instance, throw a generic vulnerability scan
at an API and expect useful results. I’ve often run these scans against vulnerable APIs only to receive false negatives. When APIs are not tested properly, organizations are given a false sense of security that leaves them with a
risk of being compromised.

xxiv

Introduction

Each section of this book will build upon the previous one:
Part I: How Web API Security Works   First, I will introduce you to the
basic knowledge you need about web applications and the APIs that
power them. You’ll learn about REST APIs, the main topic of this book,
as well as the increasingly popular GraphQL API format. I will also cover
the most common API-related vulnerabilities you can expect to find.
Part II: Building an API Testing Lab   In this section, you’ll build your
API hacking system and develop an understanding of the tools in play,
including Burp Suite, Postman, and a variety of others. You’ll also set up
a lab of vulnerable targets you’ll practice attacking throughout this book.
Part III: Attacking APIs   In Part III, we’ll turn to the API hacking
methodology, and I’ll walk you through performing common attacks
against APIs. Here the fun begins: you’ll discover APIs through the use
of open-source intelligence techniques, analyze them to understand
their attack surface, and finally dive into various attacks against them,
such as injections. You’ll learn how to reverse engineer an API, bypass
its authentication, and fuzz it for a variety of security issues.
Part IV: Real-World API Hacking   The final section of this book is
dedicated to showing you how API weaknesses have been exploited
in data breaches and bug bounties. You’ll learn how hackers have
employed the techniques covered throughout the book in real-world
situations. You’ll also walk through a sample attack against a GraphQL
API, adapting many of the techniques introduced earlier in the book to
the GraphQL format.
The Labs   Each chapter in Parts II and III includes a hands-on lab
that lets you practice the book’s techniques on your own. Of course,
you can use tools other than the ones presented here to complete the
activities. I encourage you to use the labs as a stepping-stone to experiment with techniques I present and then try out your own attacks.
This book is for anyone looking to begin web application hacking, as
well as penetration testers and bug bounty hunters looking to add another
skill to their repertoire. I’ve designed the text so that even beginners can
pick up the knowledge they’ll need about web applications in Part I, set up
their hacking lab in Part II, and begin hacking in Part III.

Hacking the API Restaurant
Before we begin, let me leave you with a metaphor. Imagine that an application is a restaurant. Like an API’s documentation, the menu describes
what sort of things you can order. As an intermediary between the customer
and the chef, the waiter is like the API itself; you can make requests to the
waiter based on the menu, and the waiter will bring you what you ordered.
Crucially, an API user does not need to know how the chef prepares a
dish or how the backend application operates. Instead, they should be able

Introduction

xxv

to follow a set of instructions to make a request and receive a corresponding response. Developers can then program their applications to fulfill the
request however they’d like.
As an API hacker, you’ll be probing every part of the metaphorical
restaurant. You’ll learn how the restaurant operates. You might attempt
to bypass its “bouncer” or perhaps provide a stolen authentication token.
Also, you’ll analyze the menu for ways to trick the API into giving you the
data you’re not authorized to access, perhaps by tricking the waiter into
handing you everything they have. You may even convince the API owner
into giving you the keys to the whole restaurant.
This book takes a holistic approach toward hacking APIs by guiding
you through the following topics:
•
•
•
•
•
•

Understanding how web applications work and the anatomy of web APIs
Mastering the top API vulnerabilities from a hacker’s perspective
Learning the most effective API hacking tools
Performing passive and active API reconnaissance to discover the existence of APIs, find exposed secrets, and analyze API functionality
Interacting with APIs and testing them with the power of fuzzing
Performing a variety of attacks to exploit API vulnerabilities you
discover

Throughout this book, you’ll apply an adversarial mindset to take
advantage of the functions and features of any API. The better we emulate
adversaries, the better we will be at finding weaknesses we can report to the
API provider. Together, I think we might even prevent the next big API data
breaches.

xxvi

Introduction

PART I
HOW WEB API SECURIT Y WORKS

0
P R E PA R I N G F O R YO U R
SECURIT Y TESTS

API security testing does not quite fit into
the mold of a general penetration test, nor
does it fit into that of a web application penetration test. Due to the size and complexity of
many organizations’ API attack surfaces, API penetration testing is its own unique service. In this chapter
I will discuss the features of APIs that you should include in your test and
document prior to your attack. The content in this chapter will help you
gauge the amount of activity required for an engagement, ensure that you
plan to test all features of the target APIs, and help you avoid trouble.
API penetration testing requires a well-developed scope, or an account
of the targets and features of what you are allowed to test, that ensures the
client and tester have a mutual understanding of the work being done.
Scoping an API security testing engagement comes down to a few factors:
your methodology, the magnitude of the testing, the target features, any
restrictions on testing, your reporting requirements, and whether you plan
to conduct remediation testing.

Receiving Authorization
Before you attack APIs, it is supremely important that you receive a signed
contract that includes the scope of the engagement and grants you authorization to attack the client’s resources within a specific time frame.
For an API penetration test, this contract can take the form of a signed
statement of work (SOW) that lists the approved targets, ensuring that you
and your client agree on the service they want you to provide. This includes
coming to an agreement over which aspects of an API will be tested, determining any exclusions, and setting up an agreed-upon time to perform
testing.
Double-check that the person signing the contract is a representative
of the target client who is in a position to authorize testing. Also make sure
the assets to be tested are owned by the client; otherwise, you will need to
rinse and repeat these instructions with the proper owner. Remember to
take into consideration the location where the client is hosting their APIs
and whether they are truly in a position to authorize testing against both
the software and the hardware.
Some organizations can be too restrictive with their scoping documentation. If you have the opportunity to develop the scope, I recommend
that, in your own calm words, you kindly explain to your clients that the
criminals have no scope or limitations. Real criminals do not consider
other projects that are consuming IT resources; they do not avoid the subnet with sensitive production servers or care about hacking at inconvenient
times of day. Make an effort to convince your client of the value of having
a less-restrictive engagement and then work with them to document the
particulars.
Meet with the client, spell out exactly what is going to happen, and then
document it exactly in the contract, reminder emails, or notes. If you stick
to the documented agreement for the services requested, you should be
operating legally and ethically. However, it is probably worth reducing your
risk by consulting with a lawyer or your legal department.

Threat Modeling an API Test
Threat modeling is the process used to map out the threats to an API provider.
If you model an API penetration test based on a relevant threat, you’ll be
able to choose tools and techniques directed at that attack. The best tests of
an API will be those that align with actual threats to the API provider.
A threat actor is the adversary or attacker of the API. The adversary can
be anyone, from a member of the public who stumbles upon the API with
little to no knowledge of the application to a customer using the application, a rogue business partner, or an insider who knows quite a bit about
the application. To perform a test that provides the most value to the security of the API, it is ideal to map out the probable adversary as well as their
hacking techniques.
Your testing method should follow directly from the threat actor’s
perspective, as this perspective should determine the information you are
4

Chapter 0

given about your target. If the threat actor knows nothing about the API,
they will need to perform research to determine the ways in which they
might target the application. However, a rogue business partner or insider
threat may know quite a bit about the application already without any
reconnaissance. To address these distinctions, there are three basic penetration testing approaches: black box, gray box, and white box.
Black box testing models the threat of an opportunistic attacker—
someone who may have stumbled across the target organization or its API.
In a truly black box API engagement, the client would not disclose any
information about their attack surface to the tester. You will likely start your
engagement with nothing more than the name of the company that signed
the SOW. From there, the testing effort will involve conducting reconnaissance using open-source intelligence (OSINT) to learn as much about the
target organization as possible. You might uncover the target’s attack surface by using a combination of search engine research, social media, public
financial records, and DNS information to learn as much as you can about
the organization’s domain. The tools and techniques for this approach are
covered in much more detail in Chapter 6. Once you’ve conducted OSINT,
you should have compiled a list of target IP addresses, URLs, and API endpoints that you can present to the client for review. The client should look
at your target list and then authorize testing.
A gray box test is a more informed engagement that seeks to reallocate
time spent on reconnaissance and instead invest it in active testing. When
performing a gray box test, you’ll mimic a better-informed attacker. You will
be provided information such as which targets are in and out of scope as
well as access to API documentation and perhaps a basic user account. You
might also be allowed to bypass certain network perimeter security controls.
Bug bounty programs often fall somewhere on the spectrum between
black box and gray box testing. A bug bounty program is an engagement
where a company allows hackers to test its web applications for vulnerabilities, and successful findings result in the host company providing a bounty
payment to the finder. Bug bounties aren’t entirely “black box” because
the bounty hunter is provided with approved targets, targets that are out
of scope, types of vulnerabilities that are rewarded, and allowed types
of attacks. With these restrictions in place, bug bounty hunters are only
limited by their own resources, so they decide how much time is spent on
reconnaissance in comparison to other techniques. If you are interested in
learning more about bug bounty hunting, I highly recommend Vickie Li’s
Bug Bounty Bootcamp (https://nostarch.com/bug-bounty-bootcamp).
In a white box approach, the client discloses as much information as
possible about the inner workings of their environment. In addition to
the information provided for gray box testing, this might include access to
application source code, design information, the software development kit
(SDK) used to develop the application, and more. White box testing models
the threat of an inside attacker—someone who knows the inner workings of
the organization and has access to the actual source code. The more information you are provided in a white box engagement, the more thoroughly
the target will be tested.
Preparing for Your Security Tests

5

The customer’s decision to make the engagement white box, black box,
or somewhere in between should be based on a threat model and threat
intelligence. Using threat modeling, work with your customer to profile the
organization’s likeliest attacker. For example, say you’re working with a small
business that is politically inconsequential; it isn’t part of a supply chain for
a more important company and doesn’t provide an essential service. In that
case, it would be absurd to assume that the organization’s adversary is a
well-funded advanced persistent threat (APT) like a nation-state. Using the
techniques of an APT against this small business would be like using a drone
strike on a petty thief. Instead, to provide the client with the most value, you
should use threat modeling to craft a realistic threat. In this case, the likeliest attacker might be an opportunistic, medium-skilled individual who has
stumbled upon the organization’s website and is likely to run only published
exploits against known vulnerabilities. The testing method that fits the
opportunistic attacker would be a limited black box test.
The most effective way to model a threat for a client is to conduct a
survey with them. The survey will need to reveal the client’s scope of exposure to attacks, their economic significance, their political involvement,
whether they are involved in any supply chains, whether they offer essential
services, and whether there are other potential motives for a criminal to want
to attack them. You can develop your own survey or put one together from
existing professional resources like MITRE ATT&CK (https://attack.mitre.org)
or OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_
Sheet.html).
The testing method you select will determine much of the remaining
scoping effort. Since black box testers are provided with very little information about scoping, the remaining scoping items are relevant for gray box
and white box testing.

Which API Features You Should Test
One of the main goals of scoping an API security engagement is to discover
the quantity of work you’ll have to do as part of your test. As such, you must
find out how many unique API endpoints, methods, versions, features,
authentication and authorization mechanisms, and privilege levels you’ll
need to test. The magnitude of the testing can be determined through
interviews with the client, a review of the relevant API documentation, and
access to API collections. Once you have the requested information, you
should be able to gauge how many hours it will take to effectively test the
client’s APIs.

API Authenticated Testing
Determine how the client wants to handle the testing of authenticated and
unauthenticated users. The client may want to have you test different API
users and roles to see if there are vulnerabilities present in any of the different privilege levels. The client may also want you to test a process they
use for authentication and the authorization of users. When it comes to
6

Chapter 0

API weaknesses, many of the detrimental vulnerabilities are discovered
in authentication and authorization. In a black box situation, you would
need to figure out the target’s authentication process and seek to become
authenticated.

Web Application Firewalls
In a white box engagement, you will want to be aware of any web application firewalls (WAFs) that may be in use. A WAF is a common defense mechanism for web applications and APIs. A WAF is a device that controls the
network traffic that reaches the API. If a WAF has been set up properly, you
will find out quickly during testing when access to the API is lost after performing a simple scan. WAFs can be great at limiting unexpected requests
and stopping an API security test in its tracks. An effective WAF will detect
the frequency of requests or request failures and ban your testing device.
In gray box and white box engagements, the client will likely reveal the
WAF to you, at which point you will have some decisions to make. While
opinions diverge on whether organizations should relax security for the
sake of making testing more effective, a layered cybersecurity defense is key
to effectively protecting organizations. In other words, no one should put
all their eggs into the WAF basket. Given enough time, a persistent attacker
could learn the boundaries of the WAF, figure out how to bypass it, or use a
zero-day vulnerability that renders it irrelevant.
Ideally, the client would allow your attacking IP address to bypass the
WAF or adjust their typical level of boundary security so that you can test
the security controls that will be exposed to their API consumers. As discussed earlier, making plans and decisions like this is really about threat
modeling. The best tests of an API will be those that align with actual
threats to the API provider. To get a test that provides the most value to the
security of the API, it is ideal to map out the probable adversary and their
hacking techniques. Otherwise, you’ll find yourself testing the effectiveness
of the API provider’s WAF rather than the effectiveness of their API security
controls.

Mobile Application Testing
Many organizations have mobile applications that expand the attack surface. Moreover, mobile apps often rely on APIs to transmit data within the
application and to supporting servers. You can test these APIs through
manual code review, automated source code analysis, and dynamic analysis.
Manual code review involves accessing the mobile application’s source code
and searching for potential vulnerabilities. Automated source code analysis
is similar, except it uses automated tools to assist in the search for vulnerabilities and interesting artifacts. Finally, dynamic analysis is the testing of
the application while it is running. Dynamic analysis includes intercepting
the mobile app’s client API requests and the server API responses and then
attempting to find weaknesses that can be exploited.

Preparing for Your Security Tests

7

Auditing API Documentation
An API’s documentation is a manual that describes how to use the API and
includes authentication requirements, user roles, usage examples, and API
endpoint information. Good documentation is essential to the commercial
success of any self-sufficient API. Without effective API documentation,
businesses would have to rely on training to support their consumers. For
these reasons, you can bet that your target APIs have documentation.
Yet, this documentation can be riddled with inaccuracies, outdated
information, and information disclosure vulnerabilities. As an API hacker,
you should search for your target’s API documentation and use it to your
advantage. In gray box and white box testing, an API documentation audit
should be included within the scope. A review of the documentation will
improve the security of the target APIs by exposing weaknesses, including
business logic flaws.

Rate Limit Testing
Rate limiting is a restriction on the number of requests an API consumer
can make within a given time frame. It is enforced by an API provider’s web
servers, firewall, or web application firewall and serves two important purposes for API providers: it allows for the monetization of APIs and prevents
the overconsumption of the provider’s resources. Because rate limiting is an
essential factor that allows organizations to monetize their APIs, you should
include it in your scope during API engagements.
For example, a business might allow a free-tier API user to make one
request per hour. Once that request is made, the consumer would be kept
from making any other request for an hour. However, if the user pays this
business a fee, they could make hundreds of requests per hour. Without
adequate controls in place, these non-paying API consumers could find
ways to skip the toll and consume as much data as often as they please.
Rate limit testing is not the same as denial of service (DoS) testing. DoS
testing consists of attacks that are intended to disrupt services and make the
systems and applications unavailable to users. Whereas DoS testing is meant
to assess how resilient an organization’s computing resources are, rate
limit testing seeks to bypass restrictions that limit the quantity of requests
sent within a given time frame. Attempting to bypass rate limiting will not
necessarily cause a disruption to services. Instead, bypassing rate limiting
could aid in other attacks and demonstrate a weakness in an organization’s
method of monetizing its API.
Typically, an organization publishes its API’s request limits in the API
documentation. It will read something like the following:
You may make X requests within a Y time frame. If you exceed
this limit, you will get a Z response from our web server.

Twitter, for example, limits requests based on your authorization once
you’re authenticated. The first tier can make 15 requests every 15 minutes,
and the next tier can make 180 requests every 15 minutes. If you exceed your
request limit, you will be sent an HTTP Error 420, as shown in Figure 0-1.
8

Chapter 0

Figure 0-1: Twitter HTTP status code from https://developer.twitter.com/en/docs

If insufficient security controls are in place to limit access to an API,
the API provider will lose money from consumers cheating the system,
incur additional costs due to the use of additional host resources, and find
themselves vulnerable to DoS attacks.

Restrictions and Exclusions
Unless otherwise specified in penetration testing authorization documentation, you should assume that you won’t be performing DoS and distributed
DoS (DDoS) attacks. In my experience, being authorized to do so is pretty
rare. When DoS testing is authorized, it is clearly spelled out in formal
documentation. Also, with the exception of certain adversary emulation
engagements, penetration testing and social engineering are typically kept
as separate exercises. That being said, always check whether you can use
social engineering attacks (such as phishing, vishing, and smishing) when
penetration testing.
By default, no bug bounty program accepts attempts at social engineering, DoS or DDoS attacks, attacks of customers, and access of customer
data. In situations where you could perform an attack against a user, programs normally suggest creating multiple accounts and, when the relevant
opportunity arises, attacking your own test accounts.
Additionally, particular programs or clients may spell out known
issues. Certain aspects of an API might be considered a security finding
but may also be an intended convenience feature. For example, a forgotyour-­password function could display a message that lets the end user know
whether their email or password is incorrect; this same function could grant
an attacker the ability to brute-force valid usernames and emails. The organization may have already decided to accept this risk and does not wish for
you to test it.
Pay close attention to any exclusions or restrictions in the contract.
When it comes to APIs, the program may allow for testing of specific sections of a given API and may restrict certain paths within an approved API.
For example, a banking API provider may share resources with a third party
and may not have authorization to allow testing. Thus, they may spell out
that you can attack the /api/accounts endpoint but not /api/shared/accounts.
Alternatively, the target’s authentication process may be through a third
party that you are not authorized to attack. You will need to pay close attention to the scope in order to perform legal authorized testing.

Preparing for Your Security Tests

9

Security Testing Cloud APIs
Modern web applications are often hosted in the cloud. When you attack
a cloud-hosted web application, you’re actually attacking the physical servers of cloud providers (likely Amazon, Google, or Microsoft). Each cloud
provider has its own set of penetration testing terms and services that you’ll
want to become familiar with. As of 2021, cloud providers have generally
become friendlier toward penetration testers, and far fewer of them require
authorization submissions. Still, some cloud-hosted web applications and
APIs will require you to obtain penetration testing authorization, such as
for an organization’s Salesforce APIs.
You should always know the current requirements of the target cloud
provider before attacking. The following list describes the policies of the
most common providers.
Amazon Web Services (AWS)   AWS has greatly improved its stance
on penetration testing. As of this writing, AWS allows its customers to
perform all sorts of security testing, with the exception of DNS zone
walking, DoS or DDoS attacks, simulated DoS or DDoS attacks, port
flooding, protocol flooding, and request flooding. For any exceptions
to this, you must email AWS and request permission to conduct testing.
If you are requesting an exception, make sure to include your testing
dates, any accounts and assets involved, your phone number, and a
description of your proposed attack.
Google Cloud Platform (GCP)   Google simply states that you do not
need to request permission or notify the company to perform penetration testing. However, Google also states that you must remain compliant with its acceptable use policy (AUP) and terms of service (TOS)
and stay within your authorized scope. The AUP and TOS prohibit illegal actions, phishing, spam, distributing malicious or destructive files
(such as viruses, worms, and Trojan horses), and interruption to GCP
services.
Microsoft Azure   Microsoft takes the hacker-friendly approach and
does not require you to notify the company before testing. In addition,
it has a “Penetration Testing Rules of Engagement” page that spells
out exactly what sort of penetration testing is permitted (https://www
.microsoft.com/en-us/msrc/pentest-rules-of-engagement).
At least for now, cloud providers are taking a favorable stance toward
penetration testing activities. As long as you stay up-to-date with the provider’s terms, you should be operating legally if you only test targets you are
authorized to hack and avoid attacks that could cause an interruption to
services.

DoS Testing
I mentioned that DoS attacks are often off the table. Work with the client
to understand their risk appetite for the given engagement. You should

10

Chapter 0

treat DOS testing as an opt-in service for clients who want to test the performance and reliability of their infrastructure. Otherwise, work with the
customer to see what they’re willing to allow.
DoS attacks represent a huge threat against the security of APIs. An
intentional or accidental DoS attack will disrupt the services provided by
the target organization, making the API or web application inaccessible. An
unplanned business interruption like this is usually a triggering factor for
an organization to pursue legal recourse. Therefore, be careful to perform
only the testing that you are authorized to perform!
Ultimately, whether a client accepts DoS testing as part of the scope
depends on the organization’s risk appetite, or the amount of risk an organization is willing to take on to achieve its purpose. Understanding an organization’s risk appetite can help you tailor your testing. If an organization
is cutting-edge and has a lot of confidence in its security, it may have a big
appetite for risk. An engagement tailored to a large appetite for risk would
involve connecting to every feature and running all the exploits you want.
On the opposite side of the spectrum are the very risk-averse organizations.
Engagements for these organizations will be like walking on eggshells. This
sort of engagement will have many details in the scope: any machine you
are able to attack will be spelled out, and you may need to ask permission
before running certain exploits.

Reporting and Remediation Testing
To your client, the most valuable aspect of your testing is the report you
submit to communicate your findings about the effectiveness of their API
security controls. The report should spell out the vulnerabilities you discovered during your testing and explain to the client how they can perform
remediation to improve the security of their APIs.
The final thing to check when scoping is whether the API provider
would like remediation testing. Once the client has their report, they should
attempt to fix their API vulnerabilities. Performing a retest of the previous
findings will validate that the vulnerabilities were successfully remediated.
Retesting could probe exclusively the weak spots, or it could be a full retest
to see if any changes applied to the API introduced new weaknesses.

A Note on Bug Bounty Scope
If you hope to hack professionally, a great way to get your foot in the door
is to become a bug bounty hunter. Organizations like BugCrowd and
HackerOne have created platforms that make it easy for anyone to make
an account and start hunting. In addition, many organizations run their
own bug bounty programs, including Google, Microsoft, Apple, Twitter,
and GitHub. These programs include plenty of API bug bounties, many of
which have additional incentives. For example, the Files.com bug bounty
program hosted on BugCrowd includes API-specific bounties, as shown in
Figure 0-2.
Preparing for Your Security Tests

11

Figure 0-2: The Files.com bug bounty program on BugCrowd, one of many to
incentivize API-related findings

In bug bounty programs, you should pay attention to two contracts: the
terms of service for the bug bounty provider and the scope of the program.
Violating either of these contracts could result not only in getting banned
from the bug bounty provider but legal trouble as well. The bounty provider’s terms of service will contain important information about earning
bounties, reporting findings, and the relationship between the bounty provider, testers, researchers, and hackers who participate and the target.
The scope will equip you with the target APIs, descriptions, reward
amounts, rules of engagement, reporting requirements, and restrictions.
For API bug bounties, the scope will often include the API documentation
or a link to the docs. Table 0-1 lists some of the primary bug bounty considerations you should understand before testing.
Table 0-1: Bug Bounty Testing Considerations
Targets

URLs that are approved for testing and rewards. Pay attention to
the subdomains listed, as some may be out of scope.

Disclosure terms

The rules regarding your ability to publish your findings.

Exclusions

URLs that are excluded from testing and rewards.

Testing restrictions Restrictions on the types of vulnerabilities the organization will

reward. Often, you must be able to prove that your finding can
be leveraged in a real-world attack by providing evidence of
exploitation.

Legal

Additional government regulations and laws that apply due to the
organization’s, customers’, and data center’s locations.

If you are new to bug hunting, I recommend checking out BugCrowd
University, which has an introduction video and page dedicated to API
security testing by Sadako (https://www.bugcrowd.com/resources/webinars/
api-security-testing-for-hackers). Also, check out Bug Bounty Bootcamp (No

12

Chapter 0

Starch Press, 2021), which is one of the best resources out there to get you
started in bug bounties. It even has a chapter on API hacking!
Make sure you understand the potential rewards, if any, of each type of
vulnerability before you spend time and effort on it. For example, I’ve seen
bug bounties claimed for a valid exploitation of rate limiting that the bug
bounty host considered spam. Review past disclosure submissions to see if
the organization was combative or unwilling to pay out for what seemed
like valid submissions. In addition, focus on the successful submissions that
received bounties. What type of evidence did the bug hunter provide, and
how did they report their finding in a way that made it easy for the organization to see the bug as valid?

Summary
In this chapter, I reviewed the components of the API security testing scope.
Developing the scope of an API engagement should help you understand the
method of testing to deploy as well as the magnitude of the engagement. You
should also reach an understanding of what can and can’t be tested as well
as what tools and techniques will be used in the engagement. If the testing
aspects have been clearly spelled out and you test within those specifications,
you’ll be set up for a successful API security testing engagement.
In the next chapter, I will cover the web application functionality you
will need to understand in order to know how web APIs work. If you already
understand web application basics, move on to Chapter 2, where I cover the
technical anatomy of APIs.

Preparing for Your Security Tests

13

1
H O W W E B A P P L I C AT I O N S W O R K

Before you can hack APIs, you must understand the technologies that support them. In
this chapter, I will cover everything you need
to know about web applications, including the
fundamental aspects of HyperText Transfer Protocol
(HTTP), authentication and authorization, and common web server databases. Because web APIs are powered by these technologies, understanding these basics
will prepare you for using and hacking APIs.
Web App Basics
Web applications function based on the client/server model: your web
browser, the client, generates requests for resources and sends these to
computers called web servers. In turn, these web servers send resources to

the clients over a network. The term web application refers to software that
is running on a web server, such as Wikipedia, LinkedIn, Twitter, Gmail,
GitHub, and Reddit.
In particular, web applications are designed for end-user interactivity.
Whereas websites are typically read-only and provide one-way communication from the web server to the client, web applications allow communications to flow in both directions, from server to client and from client to
server. Reddit, for example, is a web app that acts as a newsfeed of information flowing around the internet. If it were merely a website, visitors would
be spoon-fed whatever content the organization behind the site provided.
Instead, Reddit allows users to interact with the information on the site by
posting, upvoting, downvoting, commenting, sharing, reporting bad posts,
and customizing their newsfeeds with subreddits they want to see. These
features differentiate Reddit from a static website.
For an end user to begin using a web application, a conversation must
take place between the web browser and a web server. The end user initiates
this conversation by entering a URL into their browser address bar. In this
section, we’ll discuss what happens next.

The URL
You probably already know that the uniform resource locator (URL) is the
address used to locate unique resources on the internet. This URL consists
of several components that you’ll find helpful to understand when crafting API requests in later chapters. All URLs include the protocol used, the
hostname, the port, the path, and any query parameters:
Protocol://hostname[:port number]/[path]/[?query][parameters]

Protocols are the sets of rules computers use to communicate. The primary protocols used within the URL are HTTP/HTTPS for web pages and
FTP for file transfers.
The port, a number that specifies a communication channel, is only
included if the host does not automatically resolve the request to the proper
port. Typically, HTTP communications take place over port 80. HTTPS, the
encrypted version of HTTP, uses port 443, and FTP uses port 21. To access
a web app that is hosted on a nonstandard port, you can include the port
number in the URL, like so: https://www.example.com:8443. (Ports 8080 and
8443 are common alternatives for HTTP and HTTPS, respectively.)
The file directory path on the web server points to the location of the
web pages and files specified in the URL. The path used in a URL is the
same as a filepath used to locate files on a computer.
The query is an optional part of the URL used to perform functionality
such as searching, filtering, and translating the language of the requested
information. The web application provider may also use the query strings
to track certain information such as the URL that referred you to the web
page, your session ID, or your email. It starts with a question mark and contains a string that the server is programmed to process. Finally, the query
parameters are the values that describe what should be done with the given
query. For example, the query parameter lang=en following the query page?
16

Chapter 1

might indicate to the web server that it should provide the requested page
in English. These parameters consist of another string to be processed by
the web server. A query can contain multiple parameters separated by an
ampersand (&).
To make this information more concrete, consider the URL https://
twitter.com/search?q=hacking&src=typed_query. In this example, the protocol
is https, the hostname is twitter.com, the path is search, the query is ?q (which
stands for query), the query parameter is hacking, and src=typed_query is a
tracking parameter. This URL is automatically built whenever you click
the search bar in the Twitter web app, type in the search term “hacking,”
and press ENTER. The browser is programmed to form the URL in a
way that will be understood by the Twitter web server, and it collects some
tracking information in the form of the src parameter. The web server will
receive the request for hacking content and respond with hacking-related
information.

HTTP Requests
When an end user navigates to a URL using a web browser, the browser
automatically generates an HTTP request for a resource. This resource is
the information being requested—typically the files that make up a web
page. The request is routed across the internet or network to the web server,
where it is initially processed. If the request is properly formed, the web
server passes the request to the web application.
Listing 1-1 shows the components of an HTTP request sent when
authenticating to twitter.com.
POST1 /sessions2 HTTP/1.13
Host: twitter.com4
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 444
Cookie: _personalization_id=GA1.2.1451399206.1606701545; dnt=1;
username_or_email%5D=hAPI_hacker&5password%5D=NotMyPassword6%217
Listing 1-1: An HTTP request to authenticate with twitter.com

HTTP requests start with the method 1, the path of the requested
resource 2, and the protocol version 3. The method, described in the
“HTTP Methods” section later in this chapter, tells the server what you want
to do. In this case, you use the POST method to send your login credentials
to the server. The path may contain either the entire URL, the absolute
path, or the relative path of a resource. In this request, the path, /sessions,
specifies the page that handles Twitter authentication requests.
Requests include several headers, which are key-value pairs that communicate specific information between the client and the web server. Headers
begin with the header’s name, followed by a colon (:) and then the value
How Web Applications Work

17

of the header. The Host header 4 designates the domain host, twitter.com.
The User-Agent header describes the client’s browser and operating system.
The Accept headers describe which types of content the browser can accept
from the web application in a response. Not all headers are required, and
the client and server may include others not shown here, depending on the
request. For example, this request includes a Cookie header, which is used
between the client and server to establish a stateful connection (more on
this later in the chapter). If you’d like to learn more about all the different
headers, check out Mozilla’s developer page on headers (https://developer
.mozilla.org/en-US/docs/Web/HTTP/Headers).
Anything below the headers is the message body, which is the information that the requestor is attempting to have processed by the web application. In this case, the body consists of the username 5 and password 6
used to authenticate to a Twitter account. Certain characters in the body
are automatically encoded. For example, exclamation marks (!) are
encoded as %21 7. Encoding characters is one way that a web application
may securely handle characters that could cause problems.

HTTP Responses
After a web server receives an HTTP request, it will process and respond
to the request. The type of response depends on the availability of the
resource, the user’s authorization to access the resource, the health of the
web server, and other factors. For example, Listing 1-2 shows the response
to the request in Listing 1-1.
HTTP/1.11 302 Found2
content-security-policy: default-src 'none'; connect-src 'self'
location: https://twitter.com/
pragma: no-cache
server: tsa_a
set-cookie: auth_token=8ff3f2424f8ac1c4ec635b4adb52cddf28ec18b8; Max-Age=157680000;
Expires=Mon, 01 Dec 2025 16:42:40 GMT; Path=/; Domain=.twitter.com; Secure; HTTPOnly;
SameSite=None
You are being redirected.
Listing 1-2: An example of an HTTP response when authenticating to twitter.com

The web server first responds with the protocol version in use (in this
case, HTTP/1.1 1). HTTP 1.1 is currently the standard version of HTTP
used. The status code and status message 2, discussed in more detail in the
next section, are 302 Found. The 302 response code indicates that the client successfully authenticated and will be redirected to a landing page the
client is authorized to access.
Notice that, like HTTP request headers, there are HTTP response
headers. HTTP response headers often provide the browser with instructions for handling the response and security requirements. The set-cookie
header is another indication that the authentication request was successful, because the web server has issued a cookie that includes an auth_token,
18

Chapter 1

which the client can use to access certain resources. The response message
body will follow the empty line after the response headers. In this case, the
web server has sent an HTML message indicating that the client is being
redirected to a new web page.
The request and response I’ve shown here illustrates a common way in
which a web application restricts access to its resources through the use of
authentication and authorization. Web authentication is the process of proving your identity to a web server. Common forms of authentication include
providing a password, token, or biometric information (such as a fingerprint). If a web server approves an authentication request, it will respond by
providing the authenticated user authorization to access certain resources.
In Listing 1-1, we saw an authentication request to a Twitter web server
that sent a username and password using a POST request. The Twitter web
server responded to the successful authentication request with 302 Found
(in Listing 1-2). The session auth_token in the set-cookie header authorized
access to the resources associated with the hAPI_hacker Twitter account.
NOTE

HTTP traffic is sent in cleartext, meaning it’s not hidden or encrypted in any way.
Anyone who intercepted the authentication request in Listing 1-1 could read the username and password. To protect sensitive information, HTTP protocol requests can be
encrypted with Transport Layer Security (TLS) to create the HTTPS protocol.

HTTP Status Codes
When a web server responds to a request, it issues a response status code,
along with a response message. The response code signals how the web
server has handled the request. At a high level, the response code determines if the client will be allowed or denied access to a resource. It can
also indicate that a resource does not exist, there is a problem with the web
server, or requesting the given resource has resulted in being redirected to
another location.
Listings 1-3 and 1-4 illustrate the difference between a 200 response
and a 404 response, respectively.
HTTP/1.1 200 OK
Server: tsa_a
Content-length: 6552


[...]
Listing 1-3: An example of a 200 response
HTTP/1.1 404 Not Found
Server: tsa_a
Content-length: 0
Listing 1-4: An example of a 404 response
How Web Applications Work

19

The 200 OK response will provide the client with access to the requested
resource, whereas the 404 Not Found response will either provide the client with some sort of error page or a blank page, because the requested
resource was not found.
Since web APIs primarily function using HTTP, it is important to
understand the sorts of response codes you should expect to receive from
a web server, as detailed in Table 1-1. For more information about individual response codes or about web technologies in general, check out
Mozilla’s Web Docs (https://developer.mozilla.org/en-US/docs/Web/HTTP).
Mozilla has provided a ton of useful information about the anatomy of
web applications.
Table 1-1: HTTP Response Code Ranges
Response code

Response type

Description

100s

Information-based responses

Responses in the 100s are typically
related to some sort of processing
status update regarding the request.

200s

Successful responses

Responses in the 200s indicate a successful and accepted request.

300s

Redirects

Responses in the 300s are notifications of redirection. This is common to
see for a request that automatically
redirects you to the index/home page
or when you request a page from
port 80 HTTP to port 443 for HTTPS.

400s

Client errors

Responses in the 400s indicate that
something has gone wrong from the
client perspective. This is often the
type of response you will receive if
you have requested a page that does
not exist, if there is a timeout in the
response, or when you are forbidden
from viewing the page.

500s

Server errors

Responses in the 500s are indications that something has gone wrong
with the server. These include internal
server errors, unavailable services,
and unrecognized request methods.

HTTP Methods
HTTP methods request information from a web server. Also known as HTTP
verbs, the HTTP methods include GET, PUT, POST, HEAD, PATCH,
OPTIONS, TRACE, and DELETE.
GET and POST are the two most commonly used request methods. The
GET request is used to obtain resources from a web server, and the POST
request is used to submit data to a web server. Table 1-2 provides more indepth information about each of the HTTP request methods.

20

Chapter 1

Table 1-2: HTTP Methods
Method

Purpose

GET

GET requests attempt to gather resources from the web server. This
could be any resource, including a web page, user data, a video, an
address, and so on. If the request is successful, the server will provide the
resource; otherwise, the server will provide a response explaining why it
was unable to get the requested resource.

POST

POST requests submit data contained in the body of the request to a web
server. This could include client records, requests to transfer money from
one account to another, and status updates, for example. If a client submits the same POST request multiple times, the server will create multiple
results.

PUT

PUT requests instruct the web server to store submitted data under the
requested URL. PUT is primarily used to send a resource to a web server.
If a server accepts a PUT request, it will add the resource or completely
replace the existing resource. If a PUT request is successful, a new URL
should be created. If the same PUT request is submitted again, the results
should remain the same.

HEAD

HEAD requests are similar to GET requests, except they request the HTTP
headers only, excluding the message body. This request is a quick way to
obtain information about server status and to see if a given URL works.

PATCH

PATCH requests are used to partially update resources with the submitted data. PATCH requests are likely only available if an HTTP response
includes the Accept-Patch header.

OPTIONS

OPTIONS requests are a way for the client to identify all the request
methods allowed from a given web server. If the web server responds to
an OPTIONS request, it should respond with all allowed request options.

TRACE

TRACE requests are primarily used for debugging input sent from the
client to the server. TRACE asks the server to echo back the client’s original request, which could reveal that a mechanism is altering the client’s
request before it is processed by the server.

CONNECT

CONNECT requests initiate a two-way network connection. When
allowed, this request would create a proxy tunnel between the browser
and web server.

DELETE

DELETE requests ask that the server remove a given resource.

Some methods are idempotent, which means they can be used to send
the same request multiple times without changing the state of a resource
on a web server. For example, if you perform the operation of turning on
a light, then the light turns on. When the switch is already on and you try
to flip the switch on again, it remains on—nothing changes. GET, HEAD,
PUT, OPTIONS, and DELETE are idempotent.
On the other hand, non-idempotent methods can dynamically change
the results of a resource on a server. Non-idempotent methods include
POST, PATCH, and CONNECT. POST is the most commonly used method
for changing web server resources. POST is used to create new resources
on a web server, so if a POST request is submitted 10 times, there will be
10 new resources on the web server. By contrast, if an idempotent method
like PUT, typically used to update a resource, is requested 10 times, a single
resource will be overwritten 10 times.
How Web Applications Work

21

DELETE is also idempotent, because if the request to delete a resource
was sent 10 times, the resource would be deleted only once. The subsequent
times, nothing would happen. Web APIs will typically only use POST, GET,
PUT, DELETE, with POST as non-idempotent methods.

Stateful and Stateless HTTP
HTTP is a stateless protocol, meaning the server doesn’t keep track of information between requests. However, for users to have a persistent and consistent experience with a web application, the web server needs to remember
something about the HTTP session with that client. For example, if a user
is logged in to their account and adds several items to the shopping cart,
the web application needs to keep track of the state of the end user’s cart.
Otherwise, every time the user navigated to a different web page, the cart
would empty again.
A stateful connection allows the server to track the client’s actions, profile,
images, preferences, and so on. Stateful connections use small text files,
called cookies, to store information on the client side. Cookies may store sitespecific settings, security settings, and authentication-related information.
Meanwhile, the server often stores information on itself, in a cache, or on
backend databases. To continue their sessions, browsers include the stored
cookies in requests to the server, and when hacking web applications, an
attacker can impersonate an end user by stealing or forging their cookies.
Maintaining a stateful connection with a server has scaling limitations.
When a state is maintained between a client and a server, that relationship
exists only between the specific browser and the server used when the state
was created. If a user switches from, say, using a browser on one computer
to using the browser on their mobile device, the client would need to reauthenticate and create a new state with the server. Also, stateful connections
require the client to continuously send requests to the server. Challenges
start to arise when many clients are maintaining state with the same server.
The server can only handle as many stateful connections as allowed by
its computing resources. This is much more readily solved by stateless
applications.
Stateless communications eliminate the need for the server resources
required to manage sessions. In stateless communications, the server
doesn’t store session information, and every stateless request sent must
contain all the information necessary for the web server to recognize that
the requestor is authorized to access the given resources. These stateless
requests can include a key or some form of authorization header to maintain an experience similar to that of a stateful connection. The connections
do not store session data on the web app server; instead, they leverage backend databases.
In our shopping cart example, a stateless application could track
the contents of a user’s cart by updating the database or cache based on
requests that contain a certain token. The end-user experience would
appear the same, but how the web server handles the request is quite a bit
different. Since their appearance of state is maintained and the client issues
22

Chapter 1

everything needed in a given request, stateless apps can scale without the
concern of losing information within a stateful connection. Instead, any
number of servers can be used to handle requests as long as all the necessary information is included within the request and that information is
accessible on the backend databases.
When hacking APIs, an attacker can impersonate an end user by stealing or forging their token. API communications are stateless—a topic I will
explore in further detail in the next chapter.

Web Server Databases
Databases allow servers to store and quickly provide resources to clients.
For example, any social media platform that allows you to upload status
updates, photos, and videos is definitely using databases to save all that content. The social media platform could be maintaining those databases on
its own; alternatively, the databases could be provided to the platform as a
service.
Typically, a web application will store user resources by passing the
resources from frontend code to backend databases. The frontend of a web
application, which is the part of a web application that a user interacts with,
determines its look and feel and includes its buttons, links, videos, and fonts.
Frontend code usually includes HTML, CSS, and JavaScript. In addition, the
frontend could include web application frameworks like AngularJS, ReactJS,
and Bootstrap, to name a few. The backend consists of the technologies that
the frontend needs to function. It includes the server, the application, and
any databases. Backend programming languages include JavaScript, Python,
Ruby, Golang, PHP, Java, C#, and Perl, to name a handful.
In a secure web application, there should be no direct interaction
between a user and the backend database. Direct access to a database would
remove a layer of defense and open up the database to additional attacks.
When exposing technologies to end users, a web application provider
expands their potential for attack, a metric known as the attack surface.
Limiting direct access to a database shrinks the size of the attack surface.
Modern web applications use either SQL (relational) databases or
NoSQL (nonrelational) databases. Knowing the differences between SQL
and NoSQL databases will help you later tailor your API injection attacks.

SQL
Structured Query Language (SQL) databases are relational databases in which
the data is organized in tables. The table’s rows, called records, identify the
data type, such as username, email address, or privilege level. Its columns
are the data’s attributes and could include all of the different usernames,
email addresses, and privilege levels. In Tables 1-3 through 1-5, UserID,
Username, Email, and Privilege are the data types. The rows are the data
for the given table.

How Web Applications Work

23

Table 1-3: A Relational User Table
UserID

Username

111

hAPI_hacker

112

Scuttleph1sh

113

mysterioushadow

Table 1-4: A Relational Email Table
UserID

Email

111

hapi_hacker@email.com

112

scuttleph1sh@email.com

113

mysterioushadow@email.com

Table 1-5: A Relational Privilege Table
UserID

Privilege

111

admin

112

partner

113

user

To retrieve data from a SQL database, an application must craft a SQL
query. A typical SQL query to find the customer with the identification of
111 would look like this:
SELECT * FROM Email WHERE UserID = 111;

This query requests all records from the Email table that have the value
111 in the UserID column. SELECT is a statement used to obtain information
from the database, the asterisk is a wildcard character that will select all of
the columns in a table, FROM is used to determine which table to use, and
WHERE is a clause that is used to filter specific results.
There are several varieties of SQL databases, but they are queried similarly. SQL databases include MySQL, Microsoft SQL Server, PostgreSQL,
Oracle, and MariaDB, among others.
In later chapters, I’ll cover how to send API requests to detect injection vulnerabilities, such as SQL injection. SQL injection is a classic web
application attack that has been plaguing web apps for over two decades yet
remains a possible attack method in APIs.

NoSQL
NoSQL databases, also known as distributed databases, are nonrelational,
meaning they don’t follow the structures of relational databases. NoSQL
24

Chapter 1

databases are typically open-source tools that handle unstructured data
and store data as documents. Instead of relationships, NoSQL databases
store information as keys and values. Unlike SQL databases, each type of
NoSQL database will have its own unique structures, modes of querying,
vulnerabilities, and exploits. Here’s a sample query using MongoDB, the
current market share leader for NoSQL databases:
db.collection.find({"UserID": 111})

In this example, db.collection.find() is a method used to search
through a document for information about the UserID with 111 as the
value. MongoDB uses several operators that might be useful to know:
$eq  Matches values that are equal to a specified value
$gt  Matches values that are greater than a specified value
$lt  Matches values that are less than a specified value
$ne  Matches all values that are not equal to a specified value

These operators can be used within NoSQL queries to select and filter
certain information in a query. For example, we could use the previous
command without knowing the exact UserID, like so:
db.collection.find({"UserID": {$gt:110}})

This statement would find all UserIDs greater than 110. Understanding
these operators will be useful when conducting NoSQL injection attacks
later in this book.
NoSQL databases include MongoDB, Couchbase, Cassandra, IBM
Domino, Oracle NoSQL Database, Redis, and Elasticsearch, among others.

How APIs Fit into the Picture
A web application can be made more powerful if it can use the power of
other applications. Application programming interfaces (APIs) comprise a technology that facilitates communications between separate applications. In
particular, web APIs allow for machine-to-machine communications based
on HTTP, providing a common method of connecting different applications together.
This ability has opened up a world of opportunities for application providers, as developers no longer have to be experts in every facet of the functionality they want to provide to their end users. For example, let’s consider
a ridesharing app. The app needs a map to help its drivers navigate cities,
a method for processing payments, and a way for drivers and customers to
communicate. Instead of specializing in each of these different functions,
a developer can leverage the Google Maps API for the mapping function,
the Stripe API for payment processing, and the Twilio API to access SMS
messaging. The developer can combine these APIs to create a whole new
application.
How Web Applications Work

25

The immediate impact of this technology is twofold. First, it streamlines
the exchange of information. By using HTTP, web APIs can take advantage
of the protocol’s standardized methods, status codes, and client/server relationship, allowing developers to write code that can automatically handle
the data. Second, APIs allow web application providers to specialize, as they
no longer need to create every aspect of their web application.
APIs are an incredible technology with a global impact. Yet, as you’ll
see in the following chapters, they have greatly expanded the attack surface
of every application using them on the internet.

Summary
In this chapter we covered the fundamental aspects of web applications.
If you understand the general functions of HTTP requests and responses,
authentication/authorization, and databases, you will easily be able to
understand web APIs, because the underlying technology of web applications is the underlying technology of web APIs. In the next chapter we will
examine the anatomy of APIs.
This chapter is meant to equip you with just enough information to be
dangerous as an API hacker, not as a developer or application architect. If
you would like additional resources about web applications, I highly suggest
The Web Application Hackers Handbook (Wiley, 2011), Web Application Security
(O’Reilly, 2020), Web Security for Developers (No Starch Press, 2020), and The
Tangled Web (No Starch Press, 2011).

26

Chapter 1

2
T H E A N AT O M Y O F W E B A P I S

Most of what the average user knows about
a web application comes from what they
can see and click in the graphical user
interface (GUI) of their web browser. Under
the hood, APIs perform much of the work. In particular, web APIs provide a way for applications to use
the functionality and data of other applications over
HTTP to feed a web application GUI with images,
text, and videos.
This chapter covers common API terminology, types, data interchange
formats, and authentication methods and then ties this information together
with an example: observing the requests and responses exchanged during
interactions with Twitter’s API.

How Web APIs Work
Like web applications, web APIs rely on HTTP to facilitate a client/server
relationship between the host of the API (the provider) and the system or
person making an API request (the consumer).
An API consumer can request resources from an API endpoint, which is
a URL for interacting with part of the API. Each of the following examples
is a different API endpoint:
https://example.com/api/v3/users/
https://example.com/api/v3/customers/
https://example.com/api/updated_on/
https://example.com/api/state/1/
Resources are the data being requested. A singleton resource is a unique
object, such as /api/user/{user_id}. A collection is a group of resources, such
as /api/profiles/users. A subcollection refers to a collection within a particular
resource. For example, /api/user/{user_id}/settings is the endpoint to access
the settings subcollection of a specific (singleton) user.
When a consumer requests a resource from a provider, the request passes
through an API gateway, which isan API management component that acts as
an entry point to a web application. For example, as shown in Figure 2-1, end
users can access an application’s services using a plethora of devices, which
are all filtered through an API gateway. The API gateway then distributes the
requests to whichever microservice is needed to fulfill each request.
The API gateway filters bad requests, monitors incoming traffic, and
routes each request to the proper service or microservice. The API gateway
can also handle security controls such as authentication, authorization,
encryption in transit using SSL, rate limiting, and load balancing.

Mobile app

Microservice 1



Web app

API gateway

IoT app

Figure 2-1: A sample microservices architecture and API gateway

28

Chapter 2

Microservice 2

Microservice 3

A microservice is a modular piece of a web app that handles a specific
function. Microservices use APIs to transfer data and trigger actions. For
example, a web application with a payment gateway may have several different features on a single web page: a billing feature, a feature that logs
customer account information, and one that emails receipts upon purchase.
The application’s backend design could be monolithic, meaning all the services exist within a single application, or it could have a microservice architecture, where each service functions as its own standalone application.
The API consumer does not see the backend design, only the endpoints they can interact with and the resources they can access. These are
spelled out in the API contract, which is human-readable documentation
that describes how to use the API and how you can expect it to behave. API
documentation differs from one organization to another but often includes
a description of authentication requirements, user permission levels, API
endpoints, and the required request parameters. It might also include
usage examples. From an API hacker’s perspective, the documentation can
reveal which endpoints to call for customer data, which API keys you need
in order to become an administrator, and even business logic flaws.
In the following box, the GitHub API documentation for the /­ applications/
{client_id}/grants/{access_token} endpoint, taken from https://docs.github.com/
en/rest/reference/apps, is an example of quality documentation.

RE VOKE A GR ANT FOR AN APPLICATION
OAuth application owners can revoke a grant for their OAuth application and
a specific user.
DELETE /applications/{client_id}/grants/{access_token}

PAR A METERS
Name

Type

In

Description

accept

string

header

Setting to application/
vnd.github.v3+json is
recommended.

client_id

string

path

The client ID of your
GitHub app.

access_token

string

body

Required. The OAuth
access token used to
authenticate to the
GitHub API.

The Anatomy of Web APIs

29

The documentation for this endpoint includes the description of the
purpose of the API request, the HTTP request method to use when interacting with the API endpoint, and the endpoint itself, /applications, followed
by variables.
The acronym CRUD, which stands for Create, Read, Update, Delete,
describes the primary actions and methods used to interact with APIs.
Create is the process of making new records, accomplished through a POST
request. Read is data retrieval, done through a GET request. Update is how
currently existing records are modified without being overwritten and is
accomplished with POST or PUT requests. Delete is the process of erasing
records, which can be done with POST or DELETE, as shown in this example. Note that CRUD is a best practice only, and developers may implement
their APIs in other ways. Therefore, when you learn to hack APIs later on,
we’ll test beyond the CRUD methods.
By convention, curly brackets mean that a given variable is necessary
within the path parameters. The {client_id} variable must be replaced with
an actual client’s ID, and the {access_token} variable must be replaced with
your own access token. Tokens are what API providers use to identify and
authorize requests to approved API consumers. Other API documentation
might use a colon or square brackets to signify a variable (for example,
/api/v2/:customers/ or /api/:collection/:client_id).
The “Parameters” section lays out the authentication and authorization
requirements to perform the described actions, including the name of each
parameter value, the type of data to provide, where to include the data, and
a description of the parameter value.

Standard Web API Types
APIs come in standard types, each of which varies in its rules, functions,
and purpose. Typically, a given API will use only one type, but you may
encounter endpoints that don’t match the format and structure of the others or don’t match a standard type at all. Being able to recognize typical
and atypical APIs will help you know what to expect and test for as an API
hacker. Remember, most public APIs are designed to be self-service, so a
given API provider will often let you know the type of API you’ll be interacting with.
This section describes the two primary API types we’ll focus on
throughout this book: RESTful APIs and GraphQL. Later parts of the
book, as well as the book’s labs, cover attacks against RESTful APIs and
GraphQL only.

RESTful APIs
Representational State Transfer (REST) is a set of architectural constraints for
applications that communicate using HTTP methods. APIs that use REST
constraints are called RESTful (or just REST) APIs.

30

Chapter 2

REST was designed to improve upon many of the inefficiencies of other
older APIs, such as Simple Object Access Protocol (SOAP). For example, it
relies entirely on the use of HTTP, which makes it much more approachable to end users. REST APIs primarily use the HTTP methods GET, POST,
PUT, and DELETE to accomplish CRUD (as described in the section “How
Web APIs Work”).
RESTful design depends on six constraints. These constraints are
“shoulds” instead of “musts,” reflecting the fact that REST is essentially a
set of guidelines for an HTTP resource-based architecture:
1. Uniform interface: REST APIs should have a uniform interface. In
other words, the requesting client device should not matter; a mobile
device, an IoT (internet of things) device, and a laptop must all be able
to access a server in the same way.
2. Client/server: REST APIs should have a client/server architecture.
Clients are the consumers requesting information, and servers are the
providers of that information.
3. Stateless: REST APIs should not require stateful communications.
REST APIs do not maintain state during communication; it is as though
each request is the first one received by the server. The consumer will
therefore need to supply everything the provider will need in order
to act upon the request. This has the benefit of saving the provider
from having to remember the consumer from one request to another.
Consumers often provide tokens to create a state-like experience.
4. Cacheable: The response from the REST API provider should indicate
whether the response is cacheable. Caching is a method of increasing
request throughput by storing commonly requested data on the client side or in a server cache. When a request is made, the client will
first check its local storage for the requested information. If it doesn’t
find the information, it passes the request to the server, which checks
its local storage for the requested information. If the data is not there
either, the request could be passed to other servers, such as database
servers, where the data can be retrieved.
As you might imagine, if the data is stored on the client, the client can
immediately retrieve the requested data at little to no processing cost
to the server. This also applies if the server has cached a request. The
further down the chain a request has to go to retrieve data, the higher
the resource cost and the longer it takes. Making REST APIs cacheable
by default is a way to improve overall REST performance and scalability
by decreasing response times and server processing power. APIs usually manage caching with the use of headers that explain when the
requested information will expire from the cache.
5. Layered system: The client should be able to request data from an endpoint without knowing about the underlying server architecture.
6. Code on demand (optional): Allows for code to be sent to the client for
execution.

The Anatomy of Web APIs

31

REST is a style rather than a protocol, so each RESTful API may be different. It may have methods enabled beyond CRUD, its own sets of authentication requirements, subdomains instead of paths for endpoints, different
rate-limit requirements, and so on. Furthermore, developers or an organization may call their API “RESTful” without adhering to the standard,
which means you can’t expect every API you come across to meet all the
REST constraints.
Listing 2-1 shows a fairly typical REST API GET request used to find out
how many pillows are in a store’s inventory. Listing 2-2 shows the provider’s
response.
GET /api/v3/inventory/item/pillow HTTP/1.1
HOST: rest-shop.com
User-Agent: Mozilla/5.0
Accept: application/json
Listing 2-1: A sample RESTful API request
HTTP/1.1 200 OK
Server: RESTfulServer/0.1
Cache-Control: no-store
Content-Type: application/json
{
"item": {
"id": "00101",
"name": "pillow",
"count": 25
"price": {
"currency": "USD",
"value": "19.99"
}
},
}
Listing 2-2: A sample RESTful API response

This REST API request is just an HTTP GET request to the specified
URL. In this case, the request queries the store’s inventory for pillows. The
provider responds with JSON indicating the item’s ID, name, and quantity
of items in stock. If there was an error in the request, the provider would
respond with an HTTP error code in the 400 range indicating what went
wrong.
One thing to note: the rest-shop.com store provided all the information
it had about the resource “pillow” in its response. If the consumer’s application only needed the name and value of the pillow, the consumer would
need to filter out the additional information. The amount of information
sent back to a consumer completely depends on how the API provider has
programmed its API.

32

Chapter 2

REST APIs have some common headers you should become familiar
with. These are identical to HTTP headers but are more commonly seen in
REST API requests than in other API types, so they can help you identify
REST APIs. (Headers, naming conventions, and the data interchange format used are normally the best indicators of an API’s type.) The following
subsections detail some of the common REST API headers you will come
across.
Authorization
Authorization headers are used to pass a token or credentials to the API provider. The format of these headers is Authorization: .

For example, take a look at the following authorization header:
Authorization: Bearer Ab4dtok3n

There are different authorization types. Basic uses base64-encoded credentials. Bearer uses an API token. Finally, AWS-HMAC-SHA256 is an AWS authorization type that uses an access key and a secret key.
Content Type
Content-Type headers are used to indicate the type of media being transferred. These headers differ from Accept headers, which state the media
type you want to receive; Content-Type headers describe the media you’re

sending.
Here are some common Content-Type headers for REST APIs:
application/json  Used to specify JavaScript Object Notation (JSON) as

a media type. JSON is the most common media type for REST APIs.
application/xml  Used to specify XML as a media type.
application/x-www-form-urlencoded  A format in which the values being
sent are encoded and separated by an ampersand (&), and an equal sign
(=) is used between key/value pairs.
Middleware (X) Headers
X- headers are known as middleware headers and can serve all

sorts of purposes. They are fairly common outside of API requests as well.
X-Response-Time can be used as an API response to indicate how long a
response took to process. X-API-Key can be used as an authorization header
for API keys. X-Powered-By can be used to provide additional information
about backend services. X-Rate-Limit can be used to tell the consumer
how many requests they can make within a given time frame. X-RateLimitRemaining can tell a consumer how many requests remain before they violate rate-limit enforcement. (There are many more, but you get the idea.)
X- middleware headers can provide a lot of useful information to
API consumers and hackers alike.

The Anatomy of Web APIs

33

ENCODING DATA
As we touched upon in Chapter 1, HTTP requests use encoding as a method
to ensure that communications are handled properly. Various characters that
can be problematic for the technologies used by the server are known as bad
characters. One way of handling bad characters is to use an encoding scheme
that formats the message in such a way as to remove them. Common encoding schemes include Unicode encoding, HTML encoding, URL encoding, and
base64 encoding. XML typically uses one of two forms of Unicode encoding:
UTF-8 or UTF-16.
When the string “hAPI hacker” is encoded in UTF-8, it becomes the following:
\x68\x41\x50\x49\x20\x68\x61\x63\x6B\x65\x72
Here is the UTF-16 version of the string:
\u{68}\u{41}\u{50}\u{49}\u{20}\u{68}\u{61}\u{63}\u{6b}\u{65}\u{72}
Finally, here is the base64-encoded version:
aEFQSSBoYWNrZXI=
Recognizing these encoding schemes will be useful as you begin examining requests and responses and encounter encoded data.

GraphQL
Short for Graph Query Language, GraphQL is a specification for APIs that
allow clients to define the structure of the data they want to request from
the server. GraphQL is RESTful, as it follows the six constraints of REST
APIs. However, GraphQL also takes the approach of being query-centric,
because it is structured to function similarly to a database query language
like Structured Query Language (SQL).
As you might gather from the specification’s name, GraphQL stores the
resources in a graph data structure. To access a GraphQL API, you’ll typically access the URL where it is hosted and submit an authorized request
that contains query parameters as the body of a POST request, similar to
the following:
query {
users {
username
id
email
}
}

34

Chapter 2

In the right context, this query would provide you with the usernames,
IDs, and emails of the requested resources. A GraphQL response to this
query would look like the following:
{
"data": {
"users": {
"username": "hapi_hacker",
"id": 1111,
"email": "hapihacker@email.com"
}
}
}

GraphQL improves on typical REST APIs in several ways. Since
REST APIs are resource based, there will likely be instances when a consumer needs to make several requests in order to get all the data they
need. On the other hand, if a consumer only needs a specific value from
the API provider, the consumer will need to filter out the excess data. With
GraphQL, a consumer can use a single request to get the exact data they
want. That’s because, unlike REST APIs, where clients receive whatever
data the server is programmed to return from an endpoint, including the
data they don’t need, GraphQL APIs let clients request specific fields from
a resource.
GraphQL also uses HTTP, but it typically depends on a single entry
point (URL) using the POST method. In a GraphQL request, the body of
the POST request is what the provider processes. For example, take a look
at the GraphQL request in Listing 2-3 and the response in Listing 2-4,
depicting a request to check a store’s inventory for graphics cards.
POST /graphql HTTP/1.1
HOST: graphql-shop.com
Authorization: Bearer ab4dt0k3n
{query1 {
inventory2 (item:"Graphics Card", id: 00101) {
name
fields3{
price
quantity} } }
}
Listing 2-3: An example GraphQL request
HTTP/1.1 200 OK
Content-Type: application/json
Server: GraphqlServer

The Anatomy of Web APIs

35

{
"data": {
"inventory": { "name": "Graphics Card",
"fields":4[
{
"price":"999.99"
"quantity": 25 } ] } }
}
Listing 2-4: An example GraphQL response

As you can see, a query payload in the body specifies the information
needed. The GraphQL request body begins with the query operation 1,
which is the equivalent of a GET request and used to obtain information
from the API. The GraphQL node we are querying for, "inventory" 2, is
also known as the root query type. Nodes, similar to objects, are made up
of fields 3, similar to key/value pairs in REST. The main difference here is
that we can specify the exact fields we are looking for. In this example, we
are looking for the “price” and “quantity” fields. Finally, you can see that
the GraphQL response only provided the requested fields for the specified graphics card 4. Instead of getting the item ID, item name, and other
superfluous information, the query resolved with only the fields that were
needed.
If this had been a REST API, it might have been necessary to send
requests to different endpoints to get the quantity and then the brand of
the graphics card, but with GraphQL you can build out a query for the specific information you are looking for from a single endpoint.
GraphQL still functions using CRUD, which may sound confusing at
first since it relies on POST requests. However, GraphQL uses three operations within the POST request to interact with GraphQL APIs: query,
mutation, and subscription. Query is an operation to retrieve data (read).
Mutation is an operation used to submit and write data (create, update, and
delete). Subscription is an operation used to send data (read) when an event
occurs. Subscription is a way for GraphQL clients to listen to live updates
from the server.
GraphQL uses schemas, which are collections of the data that can be
queried with the given service. Having access to the GraphQL schema is
similar to having access to a REST API collection. A GraphQL schema will
provide you with the information you’ll need in order to query the API.
You can interact with GraphQL using a browser if there is a GraphQL
IDE, like GraphiQL, in place (see Figure 2-2).
Otherwise, you’ll need a GraphQL client such as Postman, ApolloClient, GraphQL-Request, GraphQL-CLI, or GraphQL-Compose. In later
chapters, we’ll use Postman as our GraphQL client.

36

Chapter 2

Figure 2-2: The GraphiQL interface for GitHub

SOAP: AN AC TION- ORIENTED API FORMAT
Simple Object Access Protocol (SOAP) is a type of action-oriented API that
relies on XML. SOAP is one of the older web APIs, originally released as XMLRPC back in the late 1990s, so we won’t cover it in this book.
Although SOAP works over HTTP, SMTP, TCP, and UDP, it was primarily
designed for use over HTTP. When SOAP is used over HTTP, the requests are
all made using HTTP POST. For example, take a look at the following sample
SOAP request:
POST /Inventory HTTP/1.1
Host: www.soap-shop.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

1
3

ThebestSOAP




The corresponding SOAP response looks like this:
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

(continued)

The Anatomy of Web APIs

37




4
soap:VersionMismatch