13 min to read
Pentesting APIs - Part I: Introduction & Enmumeration
The first part of the series on performing a penetration test on APIs, this part covers a general introduction on APIs and enumerating APIs during a penetration test of a bug bounty!
After a little break of making blog posts to do a deep dive on several OSCP topics (hopefully more on that soon) and juggling assessments at work, I’m back with a new series. This time it will be a series of blog posts that revolve around the topic of API penetration testing. Lately, I’ve noticed a surge in demand for API-specific penetration tests from clients of all sizes. Whether due to the rising importance of APIs in their security risk profiles or simply resource constraints. This blog post and the upcoming blog posts serve as a guide to improve your API penetration testing skills or to find a juicy bounty in your bug bounty adventures!
Introduction to Application Programming Interfaces (APIs)
To properly pentest APIs it is important to know what APIs are and how they work. In general an Application Programming Interface (or API in short) is a set of protocols that allows different software applications to communicate with each other. It defines the methods and data formats that applications can use to interact with each other, essentially acting as an intermediary that handles and processes requests made by the client and ensures that the appropriate response is delivered back to the client from the server.
A real-life comparison I always see and like of how an API works is like a waiter in a restaurant. The waiter (the API) takes orders from the customer (the client), passes the request to the kitchen (the server), and then delivers the prepared food (the response) back to the customer. The customer doesn’t interact directly with the kitchen or needs to know how it operates; they only communicate through the waiter. Similarly, applications don’t need to know the inner workings of the service they interact with via the API.
Web Applications vs APIs
While there are a lot of similarities in terms of vulnerability types and tooling used to assess the state of security on both a web application and an API, there are fundamental differences between the two. Both web application penetration testing and API penetration testing aim to identify and remediate security vulnerabilities to protect applications from potential attacks. They share common methodologies and standards, such as following the OWASP Top Ten guidelines and utilizing tools like Burp Suite, Directory Busters and Fuzzers.
However, the focus and techniques differ due to the nature of web applications and APIs. Pentesting web applications centers on the entire web application, including frontend interfaces, client-side scripts, session management, and server configurations. It involves interacting with the application through either a browser or Burp Suite. In contrast, API penetration testing concentrates on the backend services exposed by the application, interacting directly with API endpoints without a graphical user interface. It uses tools like Postman or cURL to send crafted HTTP requests, focusing on server-side logic, data validation, and how the API handles requests and responses.
Passive API Enumeration
The first step in any sort of penetration test or red team assessment is information gathering and enumeration of the target. Lets first cover passive API enumeration which consists of gathering information about an API without directly interacting with it or sending any requests to its endpoints. This technique involves examining publicly accessible resources, such as reviewing documentation of the API (in case it’s a widely used one) or exploring open-source code repositories. It’s a discreet approach that reduces the risk of triggering security alerts which gives the company you do the penetration test for a good idea of what public resources are available for that specific API.
Google Dorking
Google Dorking is a technique commonly used during information gathering or OSINT engagements, but it can also be used to enumerate APIs by discovering sensitive or publicly exposed API information. This method helps identify API keys, credentials, endpoints, and other sensitive data that may be inadvertently left exposed on public websites, Git repositories, or documentation pages. By crafting specific search queries, you can find interesting files or pages that contain valuable information related to an API, which can be a potential security risk if not properly secured. Here are some interesting Google Dorks that you can do, keep in mind to customize them for the scope you’ve been given:
# Simply find the API of a more popular website/service
Reddit API
# Look for API in the title of a specific site
intitle:"api" site:k1ngdamien.com
# Searches for configuration files containing the keyword "API_KEY"
filetype:env "API_KEY"
# Look for interesting API directories on a specific site
inurl:"/api/v1" site:k1ngdamien.com
# Look for pages that mention JSON
intitle:json site:k1ngdamien.com
# Finds all publicly available WordPress API user directories
inurl:"/wp-json/wp/v2/users"
# Finds publicly available API key files
intitle:"index.of" intext:"api.txt"
# Finds potentially interesting API directories
inurl:"/api/v1" intext:"index of /"
# Finds all sites with a XenAPI SQL injection vulnerability
ext:php inurl:"api.php?action="
# This is one of my favorite queries. It lists potentially exposed API keys
intitle:"index of" api_key OR "api key" OR apiKey -pool
Shodan
If you’re familiar with my blog, you’re all too familiar with Shodan. I won’t go into massive detail about this tool but I strongly advice you to read my blog post on it here (shameless plug). But in short, Shodan can be seen as the search engine for the internet of things (IoT) and can be used to help with API enumeration. It allows users to search for specific IPs, ports, and services to identify exposed APIs that may have weak security configurations or lack proper authentication. You can use the following queries to gather all sorts of interesting API information, make sure to align them with your scope where possible by adding a “hostname:” filter:
# Identify SSL certificates containing API references
ssl:"api"
# Search for the Content-Type header that is often accompanied in a API
"content-type: application/json"
"content-type: application/xml"
# Look for web pages with API in the title on port 8080
http.title:"API" port:8080
# Look for the Wordpress version of APIs
"wp-json"
GIT Dorking
GIT Dorking is the process of searching through publicly accessible Git repositories to uncover sensitive information which in this case could be API keys, endpoints, and configuration details, as part of passive API enumeration. This method involves using specific search terms or patterns to find exposed credentials or code snippets that developers may have accidentally committed to repositories. By exploring these repositories without directly interacting with the API, security professionals can identify potential vulnerabilities. All the queries below are expected to be places inside of the GitHub/GitLab searchbar:
# On GitHub/GitLab you can search for the term API followed by the target
k1ngdamien api
microsoft api key
# Look for comments of people suggesting a leaked API key
api key exposed
# Look for JSON files that mention or collerate with the API
extention:.json k1ngdamien
# Search for JSON files that might contain API keys
extension:json "api_key"
# In case you know a specific API key variable you can also search it
shodan_api_key
# Search for a common form of API authentication
"authorization: Bearer"
# Search for specific API related files
filename:swagger.json
The Wayback Machine
The Wayback Machine, an internet archive tool, can be used for passive API enumeration by allowing users to view historical versions of websites, which may contain outdated or deprecated API endpoints, keys, or documentation that were once public but later removed. By exploring archived snapshots of web pages or API documentation, you can uncover sensitive information that developers may have forgotten to secure. For example, an API key or endpoint visible on a previous version of a website, retrieved through the Wayback Machine, could still be valid if not properly rotated or secured. You can add an API endpoint overview like GitHub to the Wayback Machine and see if any endpoints were either added, changed or removed.
Active API Enumeration
Now it’s time for some more technical and direct enumeration. Active enumeration is all about directly interacting with your target, usually through scanning. In this phase, the goal is to uncover the target’s API endpoints and any valuable information that could give you an edge. Sometimes, you’ll get lucky and find an API advertised right on the surface, but other times, you’ll need to dig deeper. Lastly if the API is immediately connected to a web application, don’t forget to scan it for directories that might reveal API endpoints or related services.
DevTools
A browser’s DevTools is a great way to actively enumerate APIs while interacting with a web application. By opening the DevTools (usually by pressing F12), you can head over to the “Network” tab and monitor all the requests being made by the application. As you browse around the app, any API calls it makes—such as fetching data or sending user inputs—will show up here, revealing useful details like API endpoints. Another trick is to open the Debugger and check for interesting files that could contain API endpoints like config files or main files. In the example below you can see by opening the debugger, finding and interesting file, running the Javascript file through a beautifier (to make it more readable) results in the return of several API endpoints.
Fuzzing
When testing APIs I always like to use a fuzzing tool like FFUF since it is perfect for actively hunting down hidden API endpoints and resources. You can use it to brute-force directories or parameters that aren’t immediately visible on a target website. There have been multiple instances where I found “hidden” API endpoints during assessments that weren’t originally provided by the customer. With brute forcing tools like Feroxbuster and FFUF a big part of your success depends on the quality of your wordlists. In this case I always run a common wordlist like “directory-list-2.3-small.txt” or “common.txt” just in case the API endpoints contain commonly found words that aren’t that common with APIs. The best results I’ve had were API specific wordlists. SecLists has an entire section dedicated to APIs that could be used and there are tons of other wordlists that’ll be shown below, but I’d like to focus in on the wordlists provided by Assetnote. Assetnote has one of the best and most up to date wordlists at this time which are very effective against a range of older but mainly new technologies. Every month new wordlists are generated based on what’s new and hot. I highly recommend using one of these wordlists! The last noteworthy thing is to always try to use native language wordlists for your customer. With that I mean is that if you’re doing work for a Dutch customer and notice they use Dutch words in their API, use a Dutch wordlist!
# Running FFUF with a basic wordlist
ffuf -u https://example.com/api/FUZZ -w directory-list-2.3-small.txt
# Running FFUF with a more specific wordlist
ffuf -u https://example.com/api/FUZZ -w common_apis_160
# Language Specific FFUF
ffuf -u https://example.com/api/FUZZ -w common-and-dutch.txt
# Several noteworthy wordlists:
https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/api/api-endpoints.txt
https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/api/api-seen-in-wild.txt
https://wordlists.assetnote.io/
https://github.com/z5jt/API-documentation-Wordlist
KiteRunner
KiteRunner is a fantastic tool specifically built for API enumeration, helping you uncover those hidden API endpoints and routes that aren’t publicly advertised. Unlike traditional fuzzing tools, KiteRunner is optimized for API hunting and comes with its own set of API-specific wordlists to make the process even smoother. As previously mentioned, the amazing wordlists from Assetnote play a big role in Kiterunner since it’s developed by the same people! These wordlists, tailored to common API structures, make KiteRunner super effective at revealing API endpoints you can further test for security flaws. I’d say that KiteRunner, at this time, is one of the best if not THE best API enumeration tools out there.
# Running a basic Kiterunner scan
kr scan http://example.com/ -A apiroutes-240828
# Running a Kiterunner scan with a filter on the length (to remove 500s)
kr scan http://example.com/ -A apiroutes-240828 --ignore-length LENGTH
# Replaying a request in Kiterunner
kr kb replay FULL RESPONSE LINE
OWASP Amass
Finally, we’ve got Amass! This tool is a must when you want to uncover hidden subdomains and juicy network details—perfect for active API enumeration. You can use it to find subdomains that might be hosting APIs your target didn’t exactly advertise. For instance, by running an enum command, you might dig up subdomains like api.example.com or even dev-api.example.com, where test or production APIs are hiding. Below are some useful commands to execute to discover more information on APIs:
# Use AMASS to find API related domains
amass enum -active -d target-name.com | grep api
# Get a list of domains associated with the IP addresses
amass intel -addr [target IP addresses]
# Get more information about a specific domain
amass intel -d [target domain] –whois
# Passively look for information on the target domain
amass enum -passive -d [target domain]
# Actively gather information such as DNS zone transfers and SSL Cert info
amass enum -active -d [target domain]
# [LOUD] Brute-force for subdomains on the target domain
amass enum -active -brute -w [wordlist] -d [target domain] -dir [directory name]
Conclusion
That wraps up Part I of this API pentesting series. Hopefully, you’ve picked up some solid strategies to nail the enumeration phase of your next engagement. Stay tuned for Part II, where we’ll dive into the OWASP API Top 10 and the vulnerabilities lurking there. In the meantime, feel free to read one of the other, amazing, blog posts!
Comments