Introducing the API Security Workshop Learn More  

API Security Testing Tools

Property 1=API Security Testing Tools

The various  stakeholders involved in software development generally agree that they all want to release software that’s secure. No one wants applications that expose companies to the risk of a breach. Achieving this goal is not a simple matter, however. Each group of stakeholders, from developers to testers, security professionals, and enterprise architects, faces its own distinct pressures and constraints. The security of application programming interfaces (APIs), now a staple of modern application development, can be particularly challenging. This article explores why this is the case, and what can be done about the issue using API security testing tools in the development stage.

Agile development and other challenges to API security testing

To understand the need for API security testing in the development phase of the software development lifecycle (SDLC), it helps to get a sense of the various forces acting on the development process. First, there’s the overall acceleration of software development releases. It is now routine for development organizations to work using the DevOps model, which combines agile software development methodologies (Dev) with IT operations (Ops) for continuous, compressed cycles of code creation and releasing. 

DevOps is then 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 security 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 a 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 is a best practice to monitor APIs for security issues in production, it is far easier and less expensive to remediate an API security problem during development than it is after the app has gone into production. It is better to “shift left” and try to catch API security flaws before the code gets released from the CI/CD pipeline.

 

2022-security-trends-report-whitepaper

API security testing vs AppSec Testing

API security testing is just one of several types of testing that occur either at the development stage of the dev-test workflow or in the quality assurance (QA) cycle. 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. QA 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 with the goal of identifying 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 and 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 with the goal of finding 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. 

As one can see, there’s already a lot of testing going on. 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 or DAST is what’s known as “fuzzing.” A fuzzing attack involves a malicious actor using “fuzzy” approximation of the data required for an API call and seeing if he or she can get a response or break something. Like, if 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 in the process. If there are no controls restricting this type of attack, the API and the data it fronts, are at risk of breach. 

There is no one right way to do API testing, but the risks identified by the non-profit Open Web Application Security Project® (OWASP) are a good place to start. An API testing process might look at, for example, broken user authentication, a top API security concern identified by OWASP. This risk might involve incorrectly implemented API user authentication mechanisms that enable a malicious actor to compromise security tokens or 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

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 that can 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 testing based on the OWASP API Top Ten security issues, e.g., 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 suite 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, so API security testing needs to fit in easily. The testing suite can 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, they need security testing early in the SDLC. This way, the organization that owns the software avoids the trouble and expense of remediating API security problems when the application has gone into 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 involved in DevSecOps to include APIs in applications with confidence that they have been tested for security problems to the greatest extent possible.