Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer
Noname Security Logo
/
/
API Security Testing Tools

API Security Testing Tools

Harold Bell
Share this article

When you consider the unprecedented rise of data breaches and compromised mobile applications across the globe, it’s safe to say that releasing secure software has become paramount. No brand wants to be associated with faulty and vulnerable applications, nor deal with the financial consequences of exposing sensitive data. However, achieving this goal is not a simple matter.

The reality is that application programming interfaces, or APIs, are now a staple of modern application development, and can be particularly challenging to protect. From developers and testers, to security teams and enterprise architects, each group of stakeholders faces their own distinct pressures and constraints. Especially when you consider that many organizations have just only recently began testing APIs for security gaps.

With that said, we want to help you get a better understanding of the current threat environment, and highlight how API security testing tools can uncover and remediate many of these pressing issues.

Why API security testing has seen slow adoption

To understand the need for API security testing early in development, it helps to get a sense of the risk factors. First, there’s the overall speed of software development releases. It is now routine for development organizations to work using the DevOps model. DevOps combines agile software development methodologies (Dev) with IT operations (Ops) for continuous, compressed cycles of code creation and releasing.

DevOps is also often combined with continuous integration/continuous deployment (CI/CD). With CI/CD, new code is put into production whenever it is ready. This might mean adding new code to a production application on a daily, if not hourly basis. Developers and their partners in Ops are under significant pressure to keep the new code flowing. The success of digital transformation initiatives and other competitive differentiators may be at stake.

Testing and other API security tools must fit themselves into this fast-moving process. This is not always easy, with organizational factors affecting success as much, or even more than technical issues. The new discipline of DevSecOps injects security policies and security testing into the DevOps and CI/CD workflows.

If this were not already enough complexity and time pressure, consider that today’s applications frequently include API calls. Modern apps interoperate with other pieces of software and data sources, many of which may be controlled by external entities. These could be as simple as an API call to the Google Maps API. Or as sophisticated as the invoking of a stock-trading API at a Wall Street firm.

Those APIs should ideally be tested for functionality and security before the application goes into production. While it’s suggested to monitor APIs for security issues in production, it is far easier to fix security issues during development. It is better to “shift left” and try to catch API security flaws before the code gets released.

API security testing vs AppSec Testing

API security testing is just one of the types of testing that occurs during the software development or quality assurance (QA) cycles. First, apps are subject to basic functional and performance testing, i.e., does this app work the way it’s supposed to? This is of course quite important.

And no code should ever get released without going through a cycle of unit testing and functional testing. Unit tests are performed by developers. Quality assurance usually handles functional testing.

Application Security Testing (AST) involves testing an application for security vulnerabilities and other risks related to the code. Also known as AppSec testing, the process usually includes the following separate operations:

Static Application Security Testing (SAST)

Testers inspect an app’s inner workings, looking at static non-compiled source code. The goal is to identify syntax errors, input validation problems and so forth. It is also possible to do SAST with compiled code using special tools.

Dynamic Application Security Testing (DAST)

With DAST, testers use a “black box” approach. They execute code so they can inspect it at runtime. Using this approach, DAST can detect security flaws like memory leakage, defective query strings, cookie and session handling, and more.

Interactive Application Security Testing (IAST)

This approach combines SAST and DAST tools. The goal is to find a bigger range of security problems. IAST is considered better at detecting root causes of security issues.

Software Composition Analysis (SCA)

SCA is about finding security vulnerabilities in pre-built code components developers use to create applications. This almost always means open-source software, but the practice applies to commercial code as well. SCA can spot malware that’s been embedded in code libraries, for example, which are the source of supply chain attacks.

Why AppSec testing is not enough

As you can see, there is already a great deal of testing taking place. The problem is that SAST, DAST, IAST and SCA don’t do much for API security testing. At least, they can’t do it directly. An API security problem may manifest itself in SAST or DAST test results, but the root issue may not be evident.

For example, a DAST process could reveal a problem with query strings. But the actual risk is coming from a compromised API run by another entity. To figure that out, the testing team has to investigate and hopefully find that API. They may not find it however. Or, they can spend a lot of time—time they don’t have—looking for it.

Another example of API security risk that won’t get picked up by AST is what’s known as “fuzzing.” A fuzzing attack involves a malicious actor using “fuzzy” approximation of the data required for an API call. They do this in an attempt to get a response or cause havoc.

Imagine the API is expecting a user ID. The attacker can send a large number of randomly generated IDs with the hope of hitting a real user ID. If there are no controls defending against this type of attack, the API and the data it touches are at risk of breach.

One of the most serious vulnerabilities to be concerned about in that regard is broken user authentication. Often referred to as BOLA, this threat sits at the top of the list of OWASP API security concerns. Malicious actors are able to compromise security tokens and exploit other flaws in order to impersonate legitimate users’ identities. As a result, the API is exposed to the risk of unauthorized access. Standard AST practices will not pick up broken user authentication risks.

The Noname Security advantage

There is no one right way to do API testing and not all API security testing tools are created equal. While DAST offers valuable application security testing, it seldom enables the kind of API testing that modern applications require. An API security tool, such as Noname Active Testing, provides much-needed API security testing functionality. The top API Security testing tools integrate smoothly into the DevOps workflow and CI/CD pipeline.

Noname Active Testing sometimes gets confused with a DAST solution, but that is not its functionality. It is able to run over 100 dynamic API security tests on an application. These include automated testing based on the OWASP API Top Ten security issues. Vulnerabilities such as: Broken Object Level Authorization, Excessive Data Exposure, Lack of resources and Rate Limiting, Mass Assignment and Security Misconfiguration. The process relies on actual business logic, versus a “fuzzing” technique.

The testing platform can align API security tests with business objectives and team structures. While these are not technological factors, they are quite important in making the “shift left” approach viable. A lot of people from different groups have to work together to make “shift left” happen.

The testing suite should also group APIs for testing based on application, functional capabilities, business unit, or other characteristics. This drives efficiency in API security testing, which is essential for keeping up with the fast pace of DevSecOps.

Comparing APIs to their specifications is another dimension of API security testing. Noname Active Testing compares an API with its Swagger file to assess its conformance. With the ability to run this test, the dev team can import APIs from a range of sources with dynamic updates.

Conclusion

APIs are essential elements of today’s software applications. As such, organizations need to invest in dynamic API security tools – those that, among other things, empower you to test for vulnerabilities early and often. This way, at the very least, you can minimize any expenses associate remediating API security problems after production. SAST and DAST testing tools are generally not able to test APIs to the extent required.

Instead, dedicated API security testing tools and accompanying testing process should be deployed into the DevSecOps workflow. As exemplified by Noname Active Testing, this type of security testing suite enables everyone in DevSecOps to secure APIs with confidence.

Harold Bell

Harold Bell is the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.

All Harold Bell posts
Get Started Now (Tab to skip section.)

Get Started Now

Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.