When it comes to hacking APIs, there are a lot of mistakes we all make. These mistakes can often lead to failed attempts, wasted time and frustration. In order to help you avoid these pitfalls, here is a list of the five most common mistakes I see beginners make when hacking APIs.
Mistake #1 – They don’t do enough recon
It’s exciting when you come across a new API endpoint. The default behavior for many beginners is to want to jump on it right away. But that isn’t always the best idea. Sometimes, more work during the reconnaissance phase can yield far better results.
Let’s discuss just a few ways to extend your recon for better results.
Look for dev, test, and staging instances
When you stumble upon the production instances, you need to think about how the API got there. Does the target have a build, test, and deployment process that might expose other service instances?
Those instances may not have the resilience of the production deployment. It’s not uncommon for dev and/or test instances of an API that exist with much less stringent configuration and security controls. Sometimes things like WAFs and frontend balancers aren’t even configured for these instances.
And if you can find staging instances, they may not have the same production-level controls but may expose the service to production data, but with newer or older code. I’ve come across APIs in Azure Function Apps that have been sitting in a slot configuration and not yet deprovisioned… giving access to a vulnerable endpoint fixed in production but that still existed in a swapped slot during roll-out and was forgotten about.
Look for Zombie API endpoints
Staging instances are one thing. But what about production instances that have kept older code in for backward compatibility that isn’t being maintained anymore? This is one of the key artifacts of the improper assets management vulnerability described in the OWASP API Security Top 10.
If you detect versioning (either by path or by parameter), look to see if there are older versions of the endpoint that may still exist. See if they use a different data model for the objects handled in that endpoint, and determine if there may be business logic flaws, mass assignment opportunities, or other ways to manipulate how that endpoint functions from the older version.
You never know if you will find old code that may cause the “zombie apocalypse”. Always worth checking. 🙃
Make sure you complete a thorough app walkthrough
It surprises me how many beginners don’t actually learn how the target application and API work together. It’s important to invest the time to generate enough traffic to get enough coverage behind the scenes.
Get a HAR capture
I like to set up my browser to proxy through BurpSuite. I then make sure that I am recording every request in both the browser’s dev tools (network tab) and Burp’s HTTP history. I make sure I export the browser traffic directly into a HAR capture. I can then use that later when I want to generate my own API documentation. More on that in a minute.
Automatically check for authN / authZ issues
I also make sure that I complete the walkthrough in different privilege contexts. You can then leverage Burp extensions like Autorize to automatically detect authorization and authentication issues as you use the app. I’ve covered how to do that in a past article.
Make sure you test paid features
Surprisingly, especially in bug bounty hunting, few hunters are willing to pay for subscriptions or additional features of a target web application. This means the web application doesn’t typically get the same coverage as those that are tested during free trials that may not have all the same features or capabilities. If you don’t have a relationship with the target to get the highest level subscription/service for free, it might be worth spending the money for a month of service to explore those areas of the web app. You might just find new APIs that aren’t discovered during the initial walkthrough.
Map roles and permissions
In an article a few weeks ago I talked about the importance of mapping the roles and permissions of features and functions to detect where access control issues may exist in an API. This means you will need to invest the time during recon to do your walkthrough in different privilege contexts so you can see how APIs are called. Do different admin APIs exist? Do different headers or parameters alter the behavior of the app? Can you manipulate that in any way? A more thorough walkthrough during recon can help you to decide where best to attack the API first.
Mistake #2 – They don’t discover API documentation
API documentation is not just for developers. If an API publisher follows standards like the OpenAPI specification, you gain a whole lot more as an attacker. You can better discover how endpoints work. You can see what methods are used. You can determine what payloads are expected, and what the structure may be. You can even learn how the endpoint is expected to respond when unexpected or malformed data is provided.
It’s therefore important to try to secure your own copy of the API documentation.
Here’s how.
Get the documentation from the API publisher
Seems pretty simple. Go to the API vendor’s website and look for developer resources. There is a good chance they publish API documentation already.
You can also do some dorking on Google and GitHub, looking for any resources or repos that may refer to the target web API service. You might find API documentation in plain sight.
Find the API documentation through brute force enumeration
There is a great wordlist designed specifically for finding API documentation through enumeration called swagger.txt, which is part of Daniel Miessler’s SecLists repository. You can use Feroxbuster or Burp Intruder to automatically test each known path via fuzzing to detect if the API documentation exists on a target.
Check third-party API directories
Depending on the popularity of the API under test, you may find that it is cataloged in a third-party API directory. There are several API directories you can use, including:
- APIs Guru
- Postman Explore
- ProgrammableWeb API Directory
- Public APIs Github Project
- RapidAPI Hub
- SwaggerHub
In many cases, these directories will link directly to the latest version of the API documentation for you.
Generate your own rogue API documentation
I’ve previously written about how to craft your own rogue API documentation using the HAR capture you collected during your app walkthrough during your initial recon. What I like about this approach is it allows you to detect undocumented API endpoints that may not be covered in any published API documentation. You will also be able to see real-world data that is passed to and from the API to further understand the object data models expected by the code.
Mistake #3 – They don’t use disposable IP addresses
Nothing can be worse than getting banned from the target API during an engagement. Especially when you may be automating some of your recon or testing.
It’s important to understand an API’s countermeasures. Does it enforce rate-limiting? Does it use IP restrictions or blocking to ban requests that meet a certain threshold? How long before those restrictions get removed, if at all?
Usually, it’s a good idea to use a disposable IP address. This might be through a VPN service that offers tons of different exit nodes. Or ephemeral resources that you can spin up in the cloud that can get you an IP address you can throw away after using it.
TIP: Use custom identifying headers in your requests
You typically aren’t trying to hide from your target during an engagement. In fact, you want to be loud and proud so their security and OPs groups can identify your testing verse an actual attack against the API.
Consider setting a custom header that easily identifies you. As an example, if you are working on an engagement through a program on HackerOne, you might set a header like X-HackerOne-Id and add your @wearehackerone.com email alias. Or if you are working within the scope of the Microsoft Azure Bug Bounty program you might use X-MSOBB-Id and add your AzureAD user or LiveId GUID.
Whatever you use, make sure it allows the target to easily identify your traffic, especially if you are changing your IP often.
Mistake #4 – They don’t log and document enough
It’s not uncommon for beginner’s to throw a bunch of requests at an API to see what sticks. The problem with this is that it can create noisy logs and may make it harder for you to identify actual vulnerabilities. Plus it makes it difficult for the target to pinpoint testing activity vs an actual attack if you can’t cooriliate requests.
Instead, consider logging all requests and responses locally, and make sure it has a clean timestamp. This way if you do get rate-limited or blocked, you have another source of information you can use to continue your research. And it lets you look back to see how previous requests were interpreted at an earlier time.
This is where owning the professional edition of Burp Suite is ideal. You can use Burp’s project files to store all traffic that its sees during the engagement. This includes modified requests made in Repeater or Intruder. And you can save, merge and export all the interactions in a way to provide evidence required during the reporting phase of the engagement.
It also means you can record from other tools, if they support it.
Record all output from tools
So if your primary log source is something like Burp, then you want to try to ensure all your tools proxy through it too. Some tools are easy, like Postman where the UI offers an entire configuration section for it to point Postman traffic through Burp’s proxy.
You can do similar things with many command line tools you may be using during your API hacking. As an example, if you use something like feroxbuster for enumeration and fuzzing, you can use the --proxy flag to redirect all its traffic through Burp.
But what if some of your tools don’t support such configuration? Make sure you are recording their output separately. Tools like nmap include flags like -oA that can output data in several formats like XML, .nmap and .gnmap.
And if the tools don’t have any output options? Then use something like tee. The tee command, used with a pipe, reads standard input, then writes the output of a program to the screen and simultaneously copies it into the specified file.
Just remember to use a decent folder structure so you don’t lose track of all these files. Personally, I use markdown in Obsidian to track both my log files and my findings, and link them accordingly. I’ll pull individual requests that are important from Burp and drop them in markdown and ultimately use pandoc to generate formatted PDF files that maps the important log items as I go about my work.
Document data models
Look closely at every API request and response with a keen eye on building out the data models used by the endpoints. Structured objects, typically in JSON or XML format, will expose this over time.
As an example, its not uncommon to see endpoints use partial updates where the object will appear to be an entirely different structure. However, you can piece together the model and merge things by conducting different transactions on the API endpoint. ie: Make sure you record GET, POST and PUT operations and compare the objects being sent and returned. There is a good chance if you overlay them across each other, you can get a better picture of the data model for an endpoint. This can be very helpful when wanting to exploit a mass assignment vulnerability.
Mistake #5 – They give up too early
I’ve written about when to give up on an API target in the past, so I won’t go into too much detail here. But its not uncommon for a beginner to give up before they really should.
One of the main reasons is they don’t follow a structured methodology. They don’t know how to approach the target, what to do first, and in what order. I wrote about leveraging OWASP guidance as part of your blueprint to help with this in the past. But its more than that. It’s also about understanding how to stay focused and follow a predictive plan as you go through things. I covered this in the “methodology” section here.
In the end, sometimes it’s a lack of confidence in understanding what to do. Many beginners just don’t practice enough. They don’t understand the importance of mindset and being able to predict outcomes. Instead, they think hacking is all about blasting through things as fast as possible with automation tools. It’s not. API hacking is a lot more methodical than that.
If you find yourself struggling with this, my suggestion is to keep practicing and working on smaller API hacking challenges. Eventually, you’ll develop the skills and knowledge needed to move on to larger and more complex targets.
Conclusion
API hacking can be a difficult process, but with the right tools and knowledge, you can make quick work of any target. In this article, I’ve outlined 5 of the biggest mistakes that beginners make when hacking APIs. I’ve also provided some tips on how to overcome these challenges. With a little practice and patience, you too can be hacking APIs like a pro.
Want more resources on API hacking? Check out my free Ultimate Guide to API Hacking Resources.
