Tool for API and Security Testing?

I saw an interesting conversation pop up recently where someone was asking for others experiences with SoapUI and Postman for API testing. In the first instance, they planned to only use the tool they chose

to test API’s for integration testing and also test API’s between our Front end and Back end projects for our web application.

Longer-term, they wanted to choose a tool that could potentially be used for security testing so that they could do both API and security testing within the same tool.

Have you tried something similar? Is it something you would recommend? If so, what tools would you suggest and why?

1 Like

Security testing is a harder thing that I don’t think goes well with API automation. With security you want a tool that gets updates and you should understand what your runtime environment looks like. I’ve had various architects setup WAF(Web application firewalls)'s and scanning tools that get updates and run scans against an API on intervals.

If you don’t take the time to constrain it you don’t really come up with much. There are a lot of low hanging fruit OWASP top ten that can be found from scanning but the stuff that pays out from a bug crowd campaign are things dedicated security testers find. Things like cached login credentials, poorly set authorization schemes that allow the enduser to disable encryption themselves, and on and on.

There’s low hanging fruit but as far as I know no silver bullet security tool without spending time on understanding the problem space. I would love to hear that i’m wrong and there are good automated tools on the market now.



I’m the CEO of a testing automation company called Meeshkan, and this is part of the service we offer on The way we’re initially developing our service is that it tests authentication for certain popular frameworks (Spring Boot, Django, Phoenix) and certain popular providers (Okta, Auth0), although we hope to support any OAuth/JWT flow as the product grows over time.

@alanmbarr is right that this is a hard problem and it needs to be constrained. Our service only works (for now) on a small set of frameworks/languages that we can analyze to find these constraints, ie what roles exist, what scopes exist, what grants exist, what resources need what permissions, etc.

Do you know with what languages/frameworks the API you’re testing has been built? I can let you know if we support them at Meeshkan.

I thought that might be the case @alanmbarr but it’s been a long time since I looked at security testing so I’m not up to speed on what’s out there at the moment.

It’s not my project I’m afraid @mikesol so I’m not sure on the exact language/framework. If I can find the conversation again though I’ll be sure to pass your tool on :slight_smile:

1 Like

Using zed attack for security testing, you can scan the automation scripts for vulnerabilities and malicious attacks with high reporting feature.

Also you can include static code analyser in automation to do the security validations at code level.

Hope this might help

1 Like

Scans can be useful as @alanmbarr suggests, but they are a bit of a hammer to crack a nut. Fuzzing API endpoints and requests might be useful. The mutations of data that you would inject might find potential data leakages or overflow errors.

Tools like that need configuring and tuning well to reduce the impact of false positives. They will often lead to lots of unhelpful logging and errors that aren’t real problems. So it takes some experience and knowledge of your stack to really find the gnarly issues.

That being said, myself and a colleague did find a private key exposed in an old SOAP integration once, just by using some simple SQL injection. It was fixed by deprecating the code so it couldn’t be used any more. But we tried similar attacks on the new core API for the product. It simply responded with a nice, well handled exception, but didn’t barf any data.

One of the things you could do though was effect a DOS by flooding the API, as it had no rate limiting, nor did the host have sufficient capacity to cope with the throughput. At the time, (as it was a test environment) my suggestion was to see how this would cope on a production environment.

I haven’t used this myself, but it looks like an interesting tool for exploratory API testing. It’s an extension to VS Code that gives you a combination of a Jupyter notebooks like experience and a Postman like experience.

Postman in that it lets you make calls to an API, with secrets, easily seeing stuff that comes back etc. Notebooks in that your interface is a notebook. You have a GUI that lets you edit a document (notebook) that is made of cells. Each cell can have text, code or output from the code. With Jupyter notebooks the code is often Python for data analysis and the results are things like graphs. These notebooks would have code that’s calls to the API and the results are what the API returns.

I’ve used notebooks for data analysis (using R rather than Python) and they’re surprisingly nice to use. At the end you have a permanent record of your session, combining notes you’ve made (the text), exactly what code you wrote, and exactly what results you got from that code, bundled together as one notebook. You could then attach that notebook to a ticket, put it in source control etc. as it’s a text document underneath everything.

This isn’t going to replace specialist fuzzing, scanning, or performance tools, but it seemed promising for exploratory testing or just learning.