Security testing is a huge topic in it’s own right, but the intersection between API and security is an important one to consider. It can be overwhelming since there is a lot of specialist knowledge required. The truth is the majority of us do not have the ability to do a deep dive on security testing when we are testing APIs, but I think there are a few simple things that we can consider as testers.
One of the simplest things is to try out API paths with different credentials. For example, if you have an API path that allows you to edit something that is meant for admins, make sure you can’t access it as a ‘regular’ user. Another similar check to this is to try a different user’s credentials on endpoints that give back private information.
Another quick and dirty test that anyone should be able to do in API testing is try different API paths that give back the same information. Often there are multiple ways to access something in an API. For example you might have a direct endpoint that lets you get information for a particular resource. You might also be able to get to that information by using search functionality on another part of the API. Checking that the search functionality does not give you more information than it should based on your permission is something anyone can do without needing a lot of security training.
There are also system level issues to consider. Does the way your API is setup encourage or make it easy for people to accidentally expose data? Considering API design and how it interacts with human behaviour is another important place where you can provide security insights without needing security certifications.
There will be the need for security experts who are trained in the intricacies of technical security testing to take a look at your APIs, especially if they are public, but don’t let that stop you from digging in and doing your own security testing!
Photo by Bernard Hermant on Unsplash
I’m not even sure anymore where I found this, but I have found this image to be a helpful resource when I need to be reminded of what the various API status codes mean
On thing I would note about status codes, is that they aren’t always correct. The status codes need to be set by the API and sometimes APIs aren’t setup to give back the correct status code. Most APIs only use a few of these status codes and so you might get a generic error code instead of the specific one related to the issue you are actually hitting. It also happens on occasion that there are bugs in the API that return the incorrect status code. When testing you want to pay attention to the status codes, but don’t just blindly trust them
One other thing to keep in mind is that there is some ambiguity in these codes as well. Sometimes an API programmer has to make a choice as to which status code to return and different APIs will sometimes make slightly different choices in what they return. Once again you will want to pay close attention to how the API you are testing uses them. Does it make sense? Is it helpful to the users?
Status codes are an important part of API testing and are often one of the things we check in API automation, so hopefully this list is helpful for you!
Photo by rawpixel on Unsplash
I really enjoy testing APIs, but let’s face reality here: every job has its frustrations. One of the things that I have found frustrating in API testing is when an API is inadequately documented. There is something fun about digging around and figuring out what paths there are in an API and how it works, but some APIs make this too hard.
When I’ve worked with hypermedia APIs, I’ve found they generally include enough information in the calls themselves, that with a little domain knowledge you can figure them out fairly well. But I’ve also tested APIs that don’t have any self documentation and only partial external documentation. I’ve had to go digging through the code base and I’ve had to try and figure out who I could ask about stuff and kept banging my head against the API until I eventually figured out how it worked. Doing this kind of thing can get very frustrating.
As with any code, APIs need to be testable and when they are written without documentation and using magic numbers and other anti-patterns, test-ability drops. We don’t need every detail documented, but there should be enough there that someone new to the API can figure it out fairly quickly.
Photo by Steve Johnson on Unsplash
Most of the API testing I am doing at this point is exploratory testing. Currently the area I’m working in does not have a lot of test automation on the APIs. We have developer level unit tests in place on the actual implementation of the APIs, but we don’t have many regression tests that run the APIs externally.
The tools I currently use for exploring APIs are largely a mixture of Postman and Python. I have used Postman to get in and figure out what an API looks like and the basics of what it can do. Then when I want to dive deeper and perhaps throw some interesting probes at it, I’ll dig in with the requests module in python. I also use Postman to document the API so that we have a shared references for what it can do and so that I have something to come back to when things are changing. One other thing I do is use Postman or SoapUI to make mock servers so that I can do front end testing of the components.
Python can also help with doing front end testing. For one of our components we have a bunch of static ‘demo’ data that we can use. Of course that data can become stale over time and so we need to occasionally refresh it. I use python to automate this process. It can make the request to the API to get the new data and then do the cleanup need to make it work as static files.
I have also experimented with a few other tools and hope to flesh out a bit more automation as we move forward, but for now that is my API testing tool set.
Photo by Bernard Hermant on Unsplash
So the video I am going to share today isn’t explicitly about testing an API, but if you want to test something you should really understand it. I think this video is a great introduction to understanding APIs and thinking about how they work.
Note that this video mentions the Postman addon, but you will probably want to use the desktop version of Postman now.
Hope you enjoy it.
Photo by Jakob Owens on Unsplash
I didn’t have a lot of time to look at this yet, but I started poking around with Apiary
It looks like a pretty neat little tool. I’m not sure at this point if it is what I need for the work I am trying to do, but I think I will return to it to dig in a little more.
Testing needs to be woven throughout the software development process and I think tools like this can help make that a reality. So often we thing of testing as a separate column on a kanban board – something that comes after development – but we need to think of it as an integral part of the process. Having tools that let you think about testing right at the design stage is very important and it looks like there is potential in this tool that could make that a reality.
That is something I’m excited about and so I will continue to look into this and see if it indeed something we can use to move quality forward at our company!
Photo by Mantas Hesthaven on Unsplash
Today’s challenge is about explaining mocks, stubs and fakes.
I don’t know if I can pull it off.
The problem is, different teams will use these words in different ways. I don’t think it makes a lot of sense to argue about what exactly each of them means and how they are distinct from each other, but there is some value in at least understanding the general idea that these terms are meant to communicate.
In the broadest terms, when we talk about these things we are talking about something that is a substitute for a piece of production code. For example, we might have a database that stores some values. When running tests though, it might expensive to go retrieve those values many times, so instead we might make a local text file that has a few of the values we care about hard coded into it and just use that instead of the ‘real’ databases.
No matter what term we are talking about – mocking, stubbing, faking, etc. – what we are doing is using something that is not the production code to simplify in some way what we are doing for our tests. This helps us isolate things to just the specific part of the code we are interested in and can be used in some really powerful ways.
I wouldn’t worry too much about understanding in an absolute sense what these various terms means. What matters in figuring out what they mean in your context. How do the members of your team use these terms? What do they mean by them? How do the tools that you use talk about these things and what do they mean by it? Understanding how the terms are used in the contexts in which you work will help you better communicate with those that you work with.
The idea of mocking, stubbing or faking something is a very powerful testing concept and well worth taking the time to learn how to do, but don’t get too caught up in the specifics of the terminology.
Photo by Jelleke Vanooteghem on Unsplash