Fingers to keyboard, frozen in time. You stare at the bright, blank pixels reflecting from your laptop screen and wonder what you’ve gotten into. You’ve been asked to attack your company’s API but don’t know where to begin.
You’ve read the books. Watched the videos. Hacked the intentionally vulnerable applications in the online cyber ranges and earned a cool badge or two. But nowhere did they tell you what to do FIRST in an actual engagement.
“Do the recon,” they said. What the hell does that mean anyways?
Can you relate?
Don’t worry. It’s pretty common. Appsec pentester methodology can be quite different from traditional network pentesting. And while other people might have varying opinions, rarely is it ever shared.
At least not publicly, anyway.
So let’s fix that.
In this article, I want to cover five simple questions you should ask yourself (and maybe even the stakeholders) that will help you approach your target during an API pentest engagement and be more successful.
#1 – What is the goal of the engagement?
Before you even think about attacking an API, ask yourself what the motivation is. Not YOUR motivation… but that of the people asking for the pentest to be performed.
Why now? For what purpose? What are THEY solving for?
Is it for compliance reasons? Risk reduction? A previous breach? The list could go on and on and on. You won’t know unless you ask.
Understanding the critical event that triggered this request helps to level set everyone who is part of the engagement in understanding what needs to happen and what the ultimate end deliverable will be.
This can be difficult. You might have had the Rules of Engagement (RoE) dropped on your desk and asked to go to town without any of the backstory. Hopefully, this may be defined in the statement of work. Usually, it isn’t, though.
So if you need to, push back. Ask your team what the stakeholders are expecting out of the engagement. There IS a motive, and knowing this can be a big help.
Scoping in the RoE will be a big help here. I’ve talked about that before. Knowing what the stakeholders want to have tested allows the focus to be on the right places at the right time. Are you testing new features? Exploring improvements against previous technical debt? Against production or pre-production targets?
All these questions (and many others) come more into focus once you understand the motivation behind the engagement and what the stakeholders want to get from the end deliverable.
#2 – What technologies are used for this API?
There are enough patterns and anti-patterns in our industry now that we can understand how to approach our target by understanding the technologies being used to build out an API.
I’ve written about how to detect the programming language of an API before, but it’s more than that.
It’s not just about the programming language being used. It includes the frameworks being used. The architecture being used. Heck, it can even include how the endpoints are built, packaged, and deployed in their DevOps pipelines.
Let me give you an example. If you can determine the framework used to scaffold the API endpoints, you can make more informed decisions on what payloads you might want to craft when doing malicious taint injection testing.
It also means you can reduce the efforts towards an entire testing process if you know the likelihood of exploitation is low. An example that comes to mind is traditional SQL injection in a framework that is leveraging an Object-Relational Mapping (ORM) client.
Am I saying don’t conduct input validation testing looking for SQLi? Absolutely not. But the likelihood that you will find a direct SQL injection attack is low. But the ORM clients themselves could be vulnerable. So understanding this is important. Snyk has a great article to read up on to understand what I mean.
Reprioritizing how and when to conduct certain types of testing gets easier the more you can learn about the technologies being used. Imagine how much better endpoint discovery can be with Feroxbuster or Kiterunner if your wordlist can be tailored to look for specific patterns. Maybe it’s by file extension. Or route prefix. Or well-known routes.
Sun Tzu once said, “Know thy enemy.” Sounds like good advice.
TIP: If you ever want a stellar resource on mapping technology to methodology when it comes to your web app and API pentesting, make sure you check out HackTricks.
#3 – How can I gain access to the API documentation?
It’s important to gain access to the API documentation. This should be one of the first steps in your engagement. After all, you can’t test what you don’t understand.
Understanding an API’s structure is paramount to ensuring that you are testing as much of it as possible. You need to know what requests and responses look like so that you can properly craft payloads and interrogate return values. Not having this understanding will render parts of your tests moot if not done correctly.
Accessing API documentation usually isn’t a problem. Still, there are cases where it can be tricky locating them, or they need some authentication steps before accessing the contents.
If you can’t access the API documentation directly, then I recommend you craft your own rogue API docs. I have written in great detail about how to do this. By building out your own OpenAPI documentation, you can pull together your own API client using Postman and leverage that during the attack phase of your engagement.
There are secondary benefits as well… like being able to then automate testing using Postman collections for payload injection.
But it all starts with clear, clean, and complete API documentation.
#4 – How can I gain access to the source code of the API?
Gaining access to the source code of an API can be a challenge. This might not even be possible, depending on the type of engagement and contracts.
At least… not directly.
But if you have access to it and your testing requirements include static analysis components, then this process is invaluable. Knowing how and where the endpoints are being handled will help you craft better payloads when executing dynamic tests against them.
It’s also important to consider that most APIs use more than one programming language or framework for the entire stack. Different languages/frameworks could be used in tandem depending on what feature needs to be exposed.
Knowing what areas are written in specific languages could mean knowing where certain types of vulnerabilities might be found.
For example, if a portion of the API is written in Java, you may want to pay extra attention when testing for deserialization issues. If a portion is written in NodeJS, then you may need to focus more on business logic flaws like Broken Object Level Authorization (BOLA).
Ultimately, it’s important to understand both the architecture and implementation details of an API before getting too deep into testing it. Getting access to source code can help make this task easier.
I’ve discussed why this is important when tracing API exploitability using code review and taint analysis.
I’ve also demonstrated how to gain access to source code through containerized APIs with some help from decompilation. Oh, and let’s not forget the time I shared how I hacked a .NET API in the real world with a bit of luck and reverse engineering.
The point is, with access to some form of the API’s source code, you can be exposed to a world of exploitable vulnerabilities you may never have thought about before.
#5 – What external dependencies does the API have?
Dependencies are everywhere. And APIs are no exception.
One of the most important details to gain an understanding of during a pentest is what external dependencies the API has. Are there any third-party services that it interacts with? Does it call out to other databases or APIs? Do you know if another service handles authentication? Are there queues and message brokers involved in the process flow?
These are all questions you need to answer as part of your engagement. Making sure to cover every single one can be challenging… but critical for success.
External dependencies can open up attack paths you might have never even known existed. You may find weak authentication mechanisms when digging into these external services or broken access control policies that could provide you with a way to gain access.
The key is to understand the API’s attack surface, including any external services it interacts with. Make sure you take sufficient time to research these services and determine what kind of vulnerabilities they may be exposed to. All too often, pentesters only focus on the code in front of them, but if they forget about external dependencies, they could miss out on some serious problems.
At times, this can also involve researching software libraries used by an application as well. Whether open-source or commercial, understanding how those components interact with your API can be highly beneficial to break-testing success.
I wrote about that when we discussed how to use a software bill of material (SBOM) to help you attack an API. The benefits here are all about understanding the depth of third-party dependency trust and the problem with the typical window of exposure of a vulnerability. The cascading effects of dependency trust can take days, weeks, or even months to get an exploitable vulnerability in a trusted component fixed that may be impacting the API code.
This gives you a significant advantage when attacking APIs as you can detect vulnerabilities much deeper into the API than ever before and abuse that during the pentest engagement for a more extended period of time.
It’s important to review all possible external dependencies during API pentesting. Doing so can provide insight into attack paths that would be otherwise ignored and can lead to finding some serious vulnerabilities that may have been otherwise missed.
So there you have it. These five simple questions are invaluable for any API pentest engagement. Asking the right questions, understanding the architecture of the API, being aware of its external dependencies, and reviewing source code can all help make your API pentest more successful.
Taking time to properly prepare before starting a test will go a long way in helping you ensure you don’t miss anything. Good luck!
Found this article helpful? Then check out my free ebook on the Ultimate Guide to API Hacking Resources, which points you to many other useful online resources on the subject.