Creating compelling proof of concept (PoC) API exploits is vital for demonstrating the existence and impact of security vulnerabilities. A well-structured PoC not only validates the flaw but also aids stakeholders in understanding its severity and the steps needed for remediation.
But a PoC is only helpful to a person who can read and understand it.
I’ve talked before about why writing API exploits is important when reporting vulnerabilities. But I’ve never really explained what should be included in your exploits.
Here are five tips that should be considered when writing a PoC. Implementing these will improve how your API exploits work and get used.
TIP 1. Choose tools and languages stakeholders actually use
What good is a PoC that cannot be understood, or run?
Make sure you understand your audience. Learn what tools they support and use.
In most cases, you want to deliver the simplest API exploit PoC that can demonstrate impact from a vulnerability. This might be something as simple as writing an exploit using cURL. Or maybe it’s a bit more complicated and requires a Python script. Heck, I’ve even shown you how to convert requests from Burp into full-fledged API exploits in Python.
You can even write the exploits in Javascript. In fact, if developers use Postman or Bruno internally, a collection with tests written in Chai.js might be appropriate.
But in most cases stick with the basics… shell scripts, Python, or PowerShell.
When possible, do not require additional third-party libraries that will force the intended recipient to install packages or code on their system that may be foreign to them.
Side Note: Not sure what the vendor expects? ASK THEM. Stop being so bashful, or using the excuse that you are not supposed to talk to the vendor in cases where you work through a crowdsourced platform like BugCrowd or HackerOne.
Make the request through their security triage process. It saves everyone time if you are on the same page regarding their expectations.
TIP 2. Be clear in your inputs and output
Your API exploit code should be “self-documenting”.
It is useful to include output that explains what is going on as the exploit runs. Prompt the executor of the code with any dynamic data/variables that may be needed (i.e., hostname, port, etc.), and give them an opportunity to abandon the attack before execution if they are uncomfortable proceeding.
Prompts and pauses are a good thing. Just don’t exhaust the user. Be clear in the output so they know what is happening without flooding their screen with useless garbage.
And screw the ASCII art and fancy colors. The user may often not have the same level of terminal emulation you are expecting and it won’t look right anyway.
TIP 3. Maintain Clean and Understandable Code
When first drafting your exploits, it is typical to use shorthand and just get the attack payload to disk. But I encourage you to slow down and put more thought into your code.
Use descriptive variables
When writing exploit or demonstration code, it’s crucial to use clear and well-documented variables. Opt for descriptive names like target_url instead of ambiguous ones like u, or counter instead of c. This enhances readability and helps others understand your code more easily.
Make configurable variables clear
Ensure that variables requiring adjustment are easily accessible—place them at the top of the file or allow them to be modified through command-line arguments. This approach prevents others from having to delve into the main code blocks to make changes, keeping configuration separate from logic.
Try not to use environment variables
Aim to keep your exploit self-contained by avoiding the use of environment variables whenever possible. If you must use them—for example, for reusable access tokens—remember to unset them after execution to maintain a clean environment.
Document your functions clearly
Use self-descriptive function and method names. For instance, run_exploit() is more informative than a vague go(), and convert_response() is clearer than conv_resp(). While shorter names save keystrokes, they can make the code harder to understand, especially for triage teams who may not be familiar with your coding style.
Include helpful comments in the code
Include comments to explain the setup and execution steps, particularly if specific conditions need to be met. Keep explanations concise; overly verbose comments may indicate that the code isn’t self-explanatory enough. Strive to write code clearly showing its intent, reducing the need for extensive commentary.
This isn’t production code. Use minimal error handling.
Since this isn’t production code, basic error handling is acceptable. If an error occurs outside the exploit’s scope, provide a clear message and allow the script to fail gracefully without complex recovery logic.
For example, there’s no need for intricate connection retry mechanisms—simply inform the user to rerun the script. However, if the exploit could destabilize a system, such as causing a service hang due to a failed buffer overflow, alert and prompt the user beforehand. In these cases, using general try/catch handlers is appropriate.
Your payloads should be simple.
Demonstrating impact doesn’t have to be elaborate. You don’t need a complex reverse shell to showcase remote code execution; triggering a calculator application or having the server send a request to services like webhook.site or requestbin.com is sufficient. Avoid relying on tools that require commercial licenses or user accounts, such as Burp Collaborator, unless you’re certain the vendor has access.
Clearly articulate tenant and/or privilege boundaries
When demonstrating cross-tenant data leaks (CTDL), document and show that both tenants are under your control and that you are authorized to access them. Use clear naming conventions like attacker and victim instead of tenant_1 and tenant_2 to make the scenario unmistakable.
Similarly, if you’re illustrating a privilege escalation vulnerability, opt for names like low_priv and high_priv rather than attacker and victim. This clarifies the privilege boundaries and simplifies the explanation of the escalation process.
TIP 4. Provide Proof of Successful Exploitation
Along with your exploit code, you should include screenshots and/or videos demonstrating your exploit.
Your visual evidence should clearly show the vulnerability being triggered and the resulting impact, such as system access, data extraction, or privilege escalation. Ensure that the evidence is easy to follow, using clear labeling or captions to guide the viewer through each step. Screencast software like Camtasia Studio makes this trivial to produce.
This is particularly important if the exploit’s outcome isn’t immediately obvious—highlight key moments where the exploit takes effect. Including both before-and-after comparisons or output logs can further clarify the success of the attack.
Ultimately, the goal is to make it as straightforward as possible for the triage team or stakeholders to understand the exploit’s significance without having to reproduce it themselves.
TIP 5. Protect your exploits and evidence
A well-crafted Proof of Concept (PoC) exploit can cause significant damage if it falls into the wrong hands. Even if your payload is designed to be benign, there’s no guarantee that others won’t modify or weaponize it. Therefore, it’s important to ensure you know exactly who is receiving your exploit and that they are getting exactly what you wrote. The same goes for any visual evidence you have collected of successful exploitation.
To safeguard your PoC exploits, consider digitally signing and encrypting them. If you can obtain the public PGP key of the security triage team (refer to their security.txt file), you can use it to ensure that only authorized personnel have access. By encrypting your exploit and applying ASCII armor, you can attach it as a text file to your report.
This approach gives you confidence that the exploit can’t be altered during submission without the digital signature breaking, thereby maintaining its integrity and confidentiality.
If this is new to you, I highly recommend you read my article on How to use GPG as a security researcher.
Conclusion
These five tips help your proof of concept exploits to be more effective, professional, and actionable. A comprehensive PoC exploit not only demonstrates the vulnerability but also facilitates prompt and appropriate remediation, ultimately enhancing the security posture of the API and protecting user data.
By focusing on clarity, evidence, and responsible disclosure, your PoC exploits will be valuable tools in your security assessments and contribute positively to the field of API security testing.
I hope these tips help in your next engagement!
One last thing…
Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly.
If you haven’t yet, subscribe at https://apihacker.blog.
