An API Security Testing Guide
Why Secure APIs?
During a recent university initiative, I got to take part with many other industry professionals in providing feedback for application projects some students created. All the projects were great – well-designed, creative, and they filled a need. One of the projects involved an app scanning QR codes at landmarks to guide visitors to important sites throughout their city.
One of my questions to them was, “How would you protect those QR codes from being manipulated to send visitors to malicious sites?” It gave them something to think about for improvement (again, the concept is great, and I was pointing out a security improvement consideration, not a design flaw).
Any time technology (or anything for that matter) is public facing, one must consider threat actors. There’s a lot of goodwill out there, and many people don’t take the step of criminal activity. But security isn’t there to stop good things from happening; it’s there to stop people from doing bad things.
Not everyone knows about APIs, we all use them nearly every day, and few of us want to mess with them. But people who routinely target digital resources have realized that APIs are an attractive way in, so API security needs to be a serious consideration.
Planning and Designing
It’s been said that the hardest thing for a writer’s wife to learn is that when he’s staring out the window, he’s working. When planning for and designing APIs, spending lots of time talking and thinking about the grand design isn’t a waste of time. Paralysis by analysis is a real thing, but failure due to lack of planning is also real.
Who’s in Charge?
Determine who’s in charge of testing, and which tests different teams will conduct across the life cycle. How big is the team? Do you need an internal and disinterested party? Unless there’s a regulatory, contractual, compliance or other similar restraint, policies and procedures can be quite creative while still adhering to secure and clean code practices.
Backend Details Matter
There’s a concept for producing excellent animation that says, “Paint the back of the drawer.” The idea is that attention to detail includes the behind-the-scenes and never-seen aspects.
Pay attention to and provide the proper resources to secure the backend databases, processes, services, and data. When thinking about confidentiality and integrity through components such as encryption and access control, remember availability, or uptime, through strategies that include resource management, redundancy, and scalability.
Avoid zombie, outdated, or shadow APIs. You can’t protect it if you don’t know you have it. And APIs can sprawl out of hand quickly.
Based on your API architecture and design, what might threat actors try to make the APIs do?
Because it’s a form of risk assessment, threat modeling is neither a shot in the dark nor gambling – it’s a way to calculate organizational risk. An organization does its best to determine what threats may actually materialize, allowing one to focus on what’s considered a real risk, not just fear tactics.
When done properly, this process further avoids the appearance of negligence if there is a breach.
Choose Your Own Adventure
Remember the CYOA books? Or perhaps you’re a Pick Your Path fan. These still-popular books are where the reader picks from the next steps made available, and that choice determines what page one turns to and what happens next. Your API testing path will be chosen by your pick of design. SOAP? REST? GraphQL? These are different technologies and play a vital role in what and how you test.
Document, document, document – this is vital, and it can be quite boring. But someone needs to do it. In the audit world, the saying goes, “If it isn’t documented, it doesn’t exist.”
A few years ago, I wrote a haiku about documentation (I presented this as part of a presentation to an audience of developers once – many groans, but also many cheers):
Is a necessary pain,
The future loves you
Details are as necessary as foundations. The foundational steps focus on strategy, and the details move toward tactical projects and tasks that are performed on a regular basis. In a recent article, NSA’s cybersecurity director said, “No need for fancy [zero]-days when these weak controls and misconfigurations allow [adversaries] access…” Testing specific controls is essential for keeping APIs secure.
Here are some specific controls to test:
- Rate limiting – ensure that an API can handle brute force and DDoS attempts
- Input Validation – make sure that input fields can’t be used to inject information to other than what’s intended (e.g., SQL, command, and content injections)
- Limit Data Exposure – what can be seen when an API is called, especially when strange or malformed information is sent and requested?
- Runtime Protection – this is the crux of API protection – are there bad actors manipulating your APIs right now?
- Fuzz testing – these tools can be used to cover multiple areas mentioned above. Common examples include OWASP ZAP, Burp Suite, and Postman.
Here are a few resources with a lot more specific information on making one’s own checklist and methodology.
Learn More About APIs
Feeling overwhelmed and want to know more about APIs? A couple of good resources are:
- Salt Security’s API Security Fundamentals provides an excellent overview of several important API security areas.
- REST API GOAT is a Docker image designed for people to get familiar with REST API security.
In web security, there’s never enough information, testing, and controls that will keep threat actors out 100%. Producing a stable, useful, even enjoyable app is what makes a business money. Because APIs are so fundamental to applications today, securing APIs is essential to maintaining trust and loyalty from customers. Protecting the data these APIs are sharing is something customers expect to be done right – getting API security processes in place now will pay dividends in the future.