I’ve just started working on a new open source project: fencer, an automated API security testing tool. Fencer runs as a command-line application and it automatically generates security test cases based on API specifications. At the moment it only supports OpenAPI 3 specifications, but I’ll gradually grow to support previous versions of OpenAPI and other types of APIs, like GraphQL, gRPC, and so on. Before I delve into the details, let me share some background about why I started this project.
Security permeates the whole process of designing, building, and operating an API. It’s tricky, and I think it requires a holistic approach - you can’t just focus on specific elements of the API interfacing layer, you’ve got to look at the whole system. You’ve got to think about configuration management, networking, database protection, robust design and data validation, and so on. Any of these elements can compromise the security of your APIs. And of course, you need to get your authentication and authorization protocols right too!
When I do an API security audit for a client, I always take a holistic approach. I look at the authentication and authorization protocols and make sure they’re correctly implemented. I assess the API design and implementation strategies, the testing plan, the infrastructure, visibility and tracing, and more. In a recent engagement, I was also asked to write a custom test suite to test some of OWASP’s top 10 API security vulnerabilities.
I had never fully automated these kinds of tests and it was a really interesting challenge. I realized it’s a lot easier to test OWASP’s vulnerabilities when you know details about the backend implementation of the API. For example, if you know the programming language used in the backend, it’s a lot easier to spot and understand stack trace footprint in the error messages. If you know the database system, it’s a lot easier to automate database injection tests. If you know the meaning of each property in the payloads, it’s a lot easier to automate surface and mass assignment attacks.
But that got me thinking. A lot of this process can be automated. Given an API specification, we can run various tests on its endpoints by playing around with its query parameters and its request payloads. For example, regardless of the database system, we can run both SQL and noSQL injection attacks through query parameters, path parameters, and request payloads for each endpoint. If user input isn’t properly validated in the API layer, and if the data layer doesn’t parameterize database queries, the injection attacks will get executed against the database.
Given an API specification, we can also test mass assignment vulnerabilities. Imagine that an API exposes a POST /orders endpoint that allows us to place orders. The POST /orders endpoint only allows us to send details about what we want to order, but it returns a full representation of the order, including its status and other metadata. By comparing the difference between the two payloads, we can attempt to modify properties that we shouldn’t be allowed to change through a PUT/PATCH /orders endpoint.
We can also make sure that all protected endpoints correctly reject unauthorized requests with a 401 or 403 status code. And given two access tokens, we can ensure that one user doesn’t have access to another user’s data. And much more.
To put this idea to the test, I’ve started working on a project to automate API security testing - fencer. The project is open source and available in GitHub. It’s pretty much work in progress, so I very much welcome suggestions and contributions. Check it out and give the repo a ⭐️!
If you’d like to give it a try, you can install it locally with pip (pip install fencer
). To run it, you need an OpenAPI specification file locally and the URL of the server, e.g.
$ fencer run --oas-file oas.yaml --base-url http://localhost:8000
I suggest trying this out against a local server to avoid breaking things in a shared environment. Specifically, don’t run this against production
If you run into issues or have questions about the code or the functionality, please do let me know!
Fencer has a few limitations currently: it only works with OpenAPI 3.1 specifications and only runs with Python 3.10+. In the coming weeks I’ll be working on expanding fencer’s compatibility with more types of APIs and older versions of Python.
The idea behind fencer is to automate as much as possible of the API security testing process. I’m starting with OWASP’s top 10 list of API security vulnerabilities, and I plan to include additional tests to cover vulnerabilities that I’ve seen in previous projects, like insecure API designs. If there are API vulnerabilities that you’d like this tool to cover, please do let me know!
Like I said before, API security testing requires a holistic approach, and of course not everything can be automated. Tools like fencer are not a replacement for a good security expert and a manual and detailed assessment of your security posture, but they can give you a decent baseline. Fencer runs tests that can be automatically generated from an API specification. It checks vulnerabilities for every documented endpoint, query parameter, or payload. Running those tests manually is time consuming, and it’s also unnecessary since they can be automated - and that’s where fencer comes in.
The obvious question is why would I build something like this? The answer is that there aren’t that many choices when it comes to open source API security testing tools. By creating an open source API security testing project, we open the door for collaboration in this area. This is very powerful, because it means people can share their knowledge and experience in API security, and fencer will benefit from that.
I’ve been testing fencer with a few of my previous clients and it was able to catch security vulnerabilities in some of their APIs. There’s a whole host of APIs that organizations fail to take seriously from a security point of view, generally APIs that are not directly consumed by external clients. For example, APIs for driving integrations between services, or to automate internal processes. However, many of those APIs are exposed in public networks (sometimes by mistake and sometimes by design), and therefore they represent a gateway into your systems and a big security risk if they’re not adequately protected.
I hope organizations start running automated security tests against all their APIs, and that those tests help to reduce the risk of API breach. Hopefully, fencer will play a key role in that process.
If you enjoyed reading this article and found it useful, you’ll like my book Microservice APIs. It teaches you everything you need to know to build APIs from the ground up, including design, documentation, implementation, testing, security, and deployments!
You can download two chapters of the book for free from this link.
You can also use the following code to obtain a 40% discount when buying the book from Manning’s website: slperalta.
The book is also available on Amazon.
I also run a very popular series of workshops, both free and paid ones, in which I teach best practices for building microservices and APIs. I’d love to see you around in one of my workshops! An updated list of upcoming workshops is always available here.