In the world of web development, single page applications (SPAs) have become the norm due to their dynamic and responsive nature. These entirely client-side GUI applications run in a desktop browser, and communicate with APIs to interact with data. But if they are client-side, why do we point our dynamic application security test (DAST) scanners at them? Aren’t the server-side APIs our real target? Learn why SPA scanning is fundamentally flawed, and how to dynamically test your APIs directly for fast, accurate results with thorough coverage of your real attack surface.
The Evolution of Web Applications
In the early days of web development, applications were typically server-rendered. Technologies like Ruby on Rails, PHP, or Java would render the entire web page on the server and send the fully formed HTML to the browser. This made it straightforward for traditional DAST scanners to crawl and test the entire application.
These scanners, despite being slow and sometimes taking hours or days to complete, were capable of providing adequate coverage because they were designed for these server-rendered applications. They could navigate through the static HTML and simulate user interactions effectively.
The Rise of Single Page Applications
Modern web architectures, however, have shifted towards SPAs, where the browser’s Javascript runtime engine runs a full-fledged client-side application typically using a framework such as REACT, Angular, or Ember.js. There are many similar frameworks, but if your application is using any of these, it’s a good sign there’s an SPA architecture. SPAs dynamically render content and communicate with backend APIs for data. Those APIs are the true target of DAST scanning, not the SPA. This client-side rendering poses a significant challenge for traditional DAST scanners.
In a SPA, there is no static HTML to crawl. Instead, the browser-based application dynamically generates HTML using JavaScript, which means the scanner needs to execute JavaScript to fully load and interact with the application. This is where traditional scanners fall short. They attempt to render the SPA and simulate user interactions in order to reach and crawl the APIs. It never works! The SPA is changing the Document Object Model (DOM) in browser-space on the fly, as the scanner attempts to read and interpret it. Sometimes, the SPA intentionally hides routes in order to confuse web discovery tools, and sometimes it happens by accident because the app is changing memory as the crawler tries to read it. Always, it’s a process with no defined endpoint (see CS halting problem). Ultimately, this method of crawling APIs is slow, error-prone, and typically finds less than 10% of the API attack surface.
The Limitations of Traditional Scanners
When a traditional DAST scanner tries to scan an SPA, it faces several limitations:
Poor API Coverage: SPAs interact heavily with backend APIs. Traditional scanners are not designed to understand and fully explore these API endpoints. They might hit a few paths but will miss most, resulting in poor coverage. In addition, an API endpoint call discovered via the SPA might not reveal all of the endpoint’s capabilities or payload options, again resulting in incomplete coverage.
Slow Performance: Attempting to render and interact with a dynamic SPA in a simulated browser environment is extremely slow. This often results in even longer scan times than for traditional server-rendered applications. Furthermore, as mentioned above, the changing nature of a SPA while being crawled invokes the halting problem, wherein, it’s impossible for a crawler to identify when it’s “done”. Frequently a SPA crawler has to be limited by a timer giving it a “best-effort” deadline.
Incomplete Results: The consolidated scan results from a traditional scanner provide limited insights into where vulnerabilities lie within the SPA, making it harder to identify root cause and fix issues.
A Better Approach with StackHawk
StackHawk addresses these challenges by focusing on direct API testing rather than trying to scan through the SPA to find the API. Here's how StackHawk makes a difference:
Local Scanning: By coming in behind the firewall, StackHawk can test each API domain and endpoint locally, leading to much faster scan times.
Comprehensive API Coverage: Using API specifications or engineering-developed test suites such as Postman Collections, StackHawk can crawl and test every single route and input parameter available in an API, ensuring 100% coverage.
Detailed and Actionable Results: StackHawk provides detailed insights into vulnerabilities within each API, making it easier to pinpoint and resolve issues.
Bridging the Gap Between Security and Development
One of the key takeaways from using StackHawk is the realization among security professionals that they need to collaborate more closely with developers to accomplish meaningful security testing. Without the expertise of the application developers, most attempts at security testing become a variant of closed-box testing with the expected poor results. Discussions about OpenAPI specifications or other engineering artifacts often lead to the conclusion that involving developers in the security testing process is a win-win-win. Developers learn about the importance of secure coding and get rapid feedback on secure code improvements, accelerating the find-fix cycle. Security gets faster, higher quality testing results and can move away from the eternal ticketing of issues, to focusing on higher level organizational issues. The organization wins across the board by enabling faster and more secure feature delivery. The security-engineering collaboration ensures that security is integrated into the development lifecycle early and often during the SDLC, leading to more secure applications at a lower cost and faster time-to-market.
Conclusion
Testing SPAs with traditional DAST scanners is a futile effort that results in poor coverage, slow performance, and incomplete results. StackHawk offers a more effective solution by focusing on API testing, providing comprehensive coverage, faster scan times, and detailed insights. This approach not only improves security testing but also fosters better collaboration between security teams and developers. If you're still scanning your front-end apps using traditional scanners, it's time to rethink your strategy and consider StackHawk for a more effective and efficient security testing process. Visit StackHawk to learn more, or signup for a free trial here.
