Traditional security testing for JS apps has focused on the front-end, but actual security issues most often lie in the backing REST API. Join StackHawk co-founder Scott Gerlach for a quick overview of why you need to rethink how you test your JS apps and how StackHawk can help you find and fix security bugs fast.
Automated Security Testing for JS Apps

AI Generated Video Summary
At StackHawk, we do application security testing, specifically dynamic application security testing. Legacy DAST tools are not effective for testing JavaScript front ends and APIs. To achieve better testing, it is essential to drive the API directly using industry standards like postman collections, OpenAPI spec, GraphQL, and introspection queries. StackHawk simplifies finding and fixing security issues in applications, integrating with CI/CD processes and providing simple descriptions and examples. Start a free trial at stackhawk.com to improve software quality.
1. Introduction to DAST and Legacy Scanners
At StackHawk, we do application security testing, specifically dynamic application security testing. DAST can help you identify and prioritize your time on what to fix. It can help you find app set bugs that are discoverable, likely exploitable in your running code. Let's look at an example of how legacy DAST scanners are ineffective when testing JavaScript front ends and APIs.
Hey, Test.js Summit. How are you? I'm Scott Gerlach, CSO and co-founder here at StackHawk. Thanks for taking time to check out StackHawk. I hope you're learning a ton of new things at Test.js Summit, and hopefully I can teach you one more.
At StackHawk, we do application security testing, specifically dynamic application security testing. Let's talk about the benefits of DAST. DAST can help you identify and prioritize your time on what to fix because it helps identify what's discoverable and likely exploitable in your running application. If you're awash in a deluge of NPM audit tasks, and it's a good idea to go after those. But often the list is long and not everything is a straight version upgrade. But also, how do you know the code that you wrote is safe? And where should you be spending your time if the upgrade path on NPM audit isn't straightforward? This is the superpower of DAST.
DAST can help you find app set bugs that are discoverable, likely exploitable in your running code. You might be thinking to yourself, but frameworks have basically prevented any of the apps that problems from happening. And yes, many frameworks have done a good job of preventing issues like SQL injections and cross-site scripting. But most all of them have the unsafe version of that to help you do your complicated things and unfortunately make mistakes. But some people don't know about DAST and those that do may have run into the problem with DAST.
Let's look at an example. Back in the old days when we built server side applications that ran the data layer and the presentation layer, everything was fine and dandy. The legacy DAST scanner could scan and test the legacy application without many problems. You get good results, identify some serious AppSec bugs and everything was hunky dory. But then something changed. Then we started building JavaScript front ends and the JavaScript front end trolled the legacy DAST scanner and I mean, trolled it. For instance, hey, when does page scrolling end? It doesn't. Where are all the forms? It depends. Legacy DAST was running along, it was happy, totally assuming it was getting all the info it needed to test these new applications. The results were terrible. Scans took forever, false positives for days, et cetera. And the worst part, there was someone else in that back seat as well. Our backing APIs are in there controlling all the data, talking to the data store backends, helping to render elements on the page and the legacy DAST scanner thinks the front end is passing all these requests to the backend. Do we end up testing the API here? No. Are we covering the API, the whole API? Probably not.
2. DAST and API Testing
Legacy DAST tools are not effective when it comes to testing JavaScript front ends and APIs. To achieve better testing and results, it is essential to drive the API directly using industry standards like postman collections, OpenAPI spec, GraphQL, and introspection queries. Testing the front end in cookie settings and DOM XSS can also uncover potential security bugs. Key features to look for in a dynamic app set testing tool include the ability to run anywhere, provide real test data, and run custom security tests. By focusing on these aspects, you can ensure faster and more accurate AppSec testing.
Are we even making simple requests to the API? Good old JavaScript front end. It depends. It depends on the browser or browser emulator the legacy DAST tool is using and how well it's driving. What elements it can see, what it can render. If you've built support into your JavaScript application front end for specific versions of specific browsers. Now you can think of this sort of like Selenium scripts. And in Selenium scripts, you write a specific test. I wanna go to this page and then I wanna click on this button and then this should show up, right? That kind of Selenium test.
DAST is like that, except for you're expecting it to find all of the possible user input paths by itself and do a good job. It's just not gonna happen. It doesn't work well. So how can we get back to better testing, better results, faster, more accurate scans, uncovering these application security bugs that are built into our JavaScript apps now? The key here is driving the API directly. Using industry standards like postman collections, OpenAPI spec, GraphQL, introspection queries, you can have direct access to the API, understand what it does and the data it's controlling and get fast, thorough tests. Nevermind if you're building an API that doesn't have a front-end at all. Mind blown. There's still good things to find in testing the front end in cookie settings and DOM XSS. Protecting all the data that you could end up potentially putting at risk is a better place to start.
What are some of the keys to look for in a dynamic app set testing tool that will help you test APIs directly? First of all, run anywhere. Should run in your CICD, should be able to run against production, but really importantly, should be able to run your local host as you're developing. Should be able to provide real test data, so in the screenshots that we've got over here, we've got the Faker library turned on so that Faker is providing data. We've actually typed in data for some values. Lots of different options to be able to say, hey, API, here's what real data looks like. Also use that with your security tests. Run custom tests for broken access control and insecure direct object access. These are two of the top 10 OWASP API security things, and they're hard to test for without knowledge about how the API works. As you're developing the API, you can write things like tenancy checks, can customer A see customer B's data. Look for stuff like, can a regular user get into the admin functions? Those are some of the really hard things to test for. Now you can write that test once and keep running it over and over and over again to make sure that the API stays secure. Like I said, you should be looking for something that's built to scan modern applications, including server side applications, single page apps, REST APIs, GraphQL APIs and SOAP APIs. All of this leads to faster AppSec testing, faster time to fix and faster getting back to your regular work of building value in the application they're building.
3. How StackHawk Works
StackHawk simplifies the process of finding and fixing security issues in your applications. The scanner and platform provide simple descriptions and examples to help you understand and identify problems. You can recreate issues using tools like curl commands and debug them in your IDE. StackHawk integrates with CI/CD processes, allowing you to receive feedback and break builds based on the severity of findings. You can also run the same AppSec tests locally before pushing code into the pipeline. Start a free trial at stackhawk.com to integrate StackHawk into your development process and improve software quality.
How does StackHawk work? Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly, fix security issues. The StackHawk scanner and platform are built around this simplicity model. When a StackHawk findings are triaged, the platform is giving you the simplest version of the information needed to help you quickly understand what the problem is, with simple descriptions and examples of patterns to help you identify anti-pattern.
Be able to recreate the issue with tools like simple curl commands to replay the attack, and then get into debug mode in your IDE and help, start stepping through the code as fast as possible to help you fix those issues and get back to your regular job. All of this is CI CD enabled. Again, you can integrate this in your CI process and importantly, get feedback in the CI process and the scan findings. This information can be used to break a build if you choose based on the severity of those untriaged findings. Most of the major CI players are integrated with StackHawk. Documentation's out on docs.stackhawk.com if you're interested. If your particular version of CI isn't listed, it's a good chance that StackHawk works with it as long as you can run Docker or a Java process.
Here's maybe the most important part. I mentioned this before, but you can run these same AppSec tests locally that you can in CI. So you can identify a problem, fix it, and validate that you fixed it locally before you push your code back into the CI CD pipeline, cross your fingers, and hope that I got it this time. I hope you've enjoyed my talk today and perhaps learn something new about StackHawk and how StackHawk can be integrated into your API development and testing workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. Thanks for watching and enjoy the rest of TestJS Summit.