DEV Community: Arturo Enrique Mata Garcia

Taming SPAs with VORTEX: How a Crawler Actually Understands React, Vue, and Angular

Arturo Enrique Mata Garcia — Thu, 10 Sep 2026 15:47:32 +0000

💡Let’s run a mental experiment.

You open a SPA built with React. You point your favorite scanner—the one you've used for years, the one that "never fails"—to audit it. You wait. It generates a neat, polished report with a nice logo and a progress bar. And it tells you: "2 routes found. 0 critical vulnerabilities."

Two routes. In an application featuring a complete dashboard, an admin panel, over forty endpoints, and half a dozen features locked behind feature flags.

The scanner isn't broken. The scanner is blind. And nobody told it.

That was, literally, the starting point of VORTEX Assessment Engine. In my previous post, I covered the overall architecture: a self-hosted engine, a native binary, zero heavy dependencies, and direct CI/CD pipeline integration. Today, I want to lift the hood and show you the piece that makes all of that actually matter: the crawler, and what happens when it steps directly inside the JavaScript instead of just staring at it from the outside.

If you're a developer, this might sting a little. If you're a DevOps engineer, you'll care about how it plugs into the pipeline. And if you're a pentester... well, you already know exactly what I'm talking about.

🧱 HTML Is No Longer a Map. It’s a Lid.

Let's look at the facts. This is what a curl response to a modern SPA looks like:

<div id="root"></div>
<script src="/static/js/main.a1b2c3.js"></script>

That is literally all there is. No <a href>, no forms, no routes, nothing that a 2000s-era HTML parser can chew on. The entire application—components, router, API calls, business logic, validations, everything—is compressed and minified inside that single .js file, and it gets built right inside the browser in real-time the moment a user hits the page.

A crawler that only knows how to read HTML is staring at a locked door with a sign saying "nothing to see here." And it actually believes it.

This isn’t a minor limitation or an academic edge case. It’s the exact reason why, year after year, we keep seeing:

Google Maps, Stripe, or Firebase API keys leaked in production for months.
Complete administrative routes (/admin, /internal, /debug) that nobody discovered because they only render after a specific menu click.
Staging or internal microservice endpoints, referenced deep inside a bundle, that a "traditional" dynamic scan never touched.

Frontend secret leakage reports aren't going down. And they won't, because the tools meant to catch them are still playing a game that ended a decade ago.

⚙️ How VORTEX Solves It: Stop Reading, Start Executing

The core design decision behind the VORTEX crawler is simple to state and much harder to build right: instead of parsing HTML, execute the application like a real user would, and observe what happens next.

     WEB APPLICATION
            │
            ▼
   ┌─────────────────┐
   │     VORTEX      │
   │     Crawler     │
   └────────┬────────┘
            │
            ▼
 Rendering + Dynamic Route Discovery
            │
            ▼
    JS Bundle Extraction & Analysis
            │
            ▼
   Attack Surface Correlation

🔍 Let's break down why that actually matters.

1. 🧭 Route Discovery: Don't Read, Navigate

VORTEX doesn't just scrape links. It interacts: it clicks, navigates, opens menus, triggers transitions, and listens to the history changes fired on-the-fly by React Router, Vue Router, or Angular Router.

Why is this a big deal? Because the most interesting routes are almost never just a single obvious click away. They hide behind:

A dropdown menu that only renders on hover.
A tab loading a lazy chunk via dynamic import().
A route guard that only mounts a component if an active session exists.

None of that exists in the initial HTML. It only exists after something happens inside the browser. And a crawler that doesn’t simulate that "something" will simply never see it.

(Yes, authentication-protected routes are a whole separate, juicy topic—VORTEX supports credentials, --login-path, and session cookie handoff to reach them—but that deserves its own dedicated post. Today, we're sticking to the core crawler.)

2. 📦 Static JS Bundle Analysis: The Mistake We've All Made at Least Once

This is, without exaggeration, my favorite part of the engine. And the most underrated feature in any DAST tool.

Put yourself in the shoes of the developer writing the code, because that’s where the problem actually starts. You're deep into a sprint, you need a map to load right now, or an analytics widget to work in the staging environment. You paste the key straight into the source code, with every intention of moving it to an environment variable "as soon as I have five minutes." The PR gets reviewed—nobody notices, because nobody is checking that line by line—it gets merged, and Webpack or Vite do their job: they minify, bundle, and that key ends up shipping, completely intact, inside the main.a1b2c3.js file served publicly to anyone opening the app.

That exact moment—the "I'll fix it later" that never comes—is the exact kind of oversight that a static JS bundle analysis is built to catch. Nobody needs to click anything, and no suspicious requests need to be fired: the file is already public, accessible to anyone with a browser and their DevTools open, and it already contains what it shouldn't.

And here’s the kicker that almost no one sees coming: most of these leaks never generate a visible HTTP request during a standard dynamic scan. They don't show up in network traffic because the issue isn't what the app does, but what the bundle contains. A purely black-box scan—one that only watches packets flying back and forth—will never touch them, because it never looked inside the file itself.

If you've ever inspected your own app's bundle "out of curiosity" and found something that shouldn't be there... you know exactly what I'm talking about. And if you haven't, it’s probably worth checking before someone less friendly than you does.

3. 🎯 Correlation: Active Testing Against Real Surface Area, Not Assumptions

Once the crawler maps out the complete route tree and finishes the JS bundle analysis, VORTEX fires active security tests—SQLi, XSS, Path Traversal, among others—directly against that discovered surface, rather than firing payloads at a handful of guessed URLs or an outdated sitemap.

 SPA / Route Discovery
            │
            ▼
 JavaScript Analysis
            │
            ▼
 Security Assessment

The practical difference: scanning cycles are concentrated where there is actually something to attack, instead of wasting time hitting ghost routes that never existed or that no real user could ever reach.

👥Why Every Technical Role Should Care

Because no, this isn't "just a security thing." It hits each role differently:

👨‍💻If you're a developer: that bundle you just pushed to production with a hardcoded VITE_API_KEY "just to test on staging"—yeah, that one—is precisely what this crawler is designed to find before an attacker does. It's not personal. It's math.
🚀 If you're a DevOps / DevSecOps engineer: finding an issue like this inside a pull request, before the merge, costs minutes of fixing and a single line in a changelog. Finding that exact same issue three weeks later in production—or worse, reported by an outside party, or worse still, exploited—costs an incident response, an awkward meeting, and likely a post-mortem. Bringing this analysis into the pipeline turns security gating into an early check rather than a late, ceremonial audit.
🕵️‍♂️If you're a pentester: you already know the frustration of wasting the first two hours of an engagement simply trying to manually map an application because the automated crawler gave up at the loading screen. An engine that handles that discovery for you—while handing you pre-analyzed bundle results—doesn't replace your judgment; it gives you back your time for what actually requires a human brain: exploitation and impact analysis.

⚡Conclusion

HTML stopped being the application map years ago. The real map lives inside the JavaScript your browser silently executes every single time you load a page. A DAST tool that doesn't understand that isn't evaluating your app: it's evaluating an empty shell with a <div id="root"></div> inside, congratulating you on how clean it looks.

If you want to see the crawler running against your own SPA, the Community Edition is still available with no credit card required. And if you test it against something built with Svelte, Solid, Qwik, or any framework outside the usual trio, let me know how it behaves—that feedback is absolute gold for keeping the engine sharp.

🔗 Useful Links & Documentation

🌐 Official Website & Docs: zerodayslab.co/docs
💻 GitHub Repository: matarturo.github.io

More Than Just a Scanner: Architecture of a Self-Hosted DAST Engine for SPAs and CI/CD

Arturo Enrique Mata Garcia — Tue, 08 Sep 2026 20:28:52 +0000

Traditional DAST tools are often a massive headache for modern development teams: they are slow, tightly coupled to third-party cloud services, and worst of all, completely blind to Single Page Applications (SPAs) built with React, Vue, or Angular where routing and application logic live entirely on the client side.

If you are shipping software fast, you need a tool that speaks your language: a native, portable binary with zero heavy runtime dependencies (no Python or pip required in production) that integrates seamlessly into your CI/CD pipelines to enforce real security gatekeeping.

Meet VORTEX Assessment Engine, developed by Arturo Mata.
Official documentation and interactive diagrams are also available at matarturo.github.io.

If you are a pentester, DevSecOps engineer, or web developer, you have likely suffered through traditional DAST tools. They are sluggish, heavy, and above all, clueless about modern web applications.

SPAs built with React, Vue, or Angular rely almost entirely on JavaScript. Legacy crawlers get lost, fail to discover dynamic routes, and let critical vulnerabilities slip by—alongside exposed frontend secrets.

VORTEX Assessment Engine was built to solve precisely that problem. It is a self-hosted, high-performance DAST engine engineered specifically to evaluate SPAs with a deep focus on JavaScript analysis and native CI/CD pipeline integration.

🔬 Architecture: A Self-Hosted Engine

Unlike commercial SaaS scanners that require shipping your application code to an external cloud, VORTEX runs entirely within your own infrastructure. This guarantees:

Privacy: Your target application never leaves your secure perimeter.
Total Control: You know exactly where and how the scan execution takes place.
Automation-First: Easily embed it into a Bash script or native pipeline step.

┌───────────────────────────────────┐
│        YOUR INFRASTRUCTURE        │
│                                   │
│   ┌───────────────────────────┐   │
│   │   VORTEX Assessment       │   │
│   │        Engine             │   │
│   └─────────────┬─────────────┘   │
│                 │                 │
│                 ▼                 │
│          WEB APPLICATION          │
│            TARGET                 │
└───────────────────────────────────┘

🕸️ Why Does VORTEX Understand SPA's?

Conventional DAST scanners rely heavily on static HTML parsing. VORTEX incorporates an SPA-optimized crawler that performs the following actions:

Renders and discovers dynamic routing structures across React, Vue, and Angular applications.

Performs deep parsing of JavaScript bundles to hunt down:
Exposed API keys
Authentication tokens
Hardcoded credentials
Sensitive internal configuration secrets

🔬 Evaluation Flow

A typical security assessment with VORTEX follows this streamlined execution sequence:

               APLICACIÓN WEB
                     │
                     ▼
            ┌─────────────────┐
            │     VORTEX      │
            │     Crawler     │
            └────────┬────────┘
                     │
                     ▼
           SPA / Route Discovery
                     │
                     ▼
          JavaScript Analysis
                     │
                     ▼
          Security Assessment
                     │
                     ▼
            ┌─────────────────┐
            │    RESULTS      │
            └────────┬────────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          HTML      JSON     SARIF

VORTEX fires targeted security tests (SQLi, XSS, Path Traversal, etc.) directly against the discovered surfaces. This rigorous JavaScript inspection uncovers severe flaws that standard black-box scanners routinely miss.

🔬 Real-World Environment Demonstration

Your browser does not support the video tag.

⚡ A Native, Frictionless Binary

VORTEX is distributed as a self-contained, native Linux binary. This design delivers distinct performance advantages:

Zero requirements for Python, pip, or fragile runtime dependencies.
No Node.js engine required on the target execution host.
Ultra-lightweight footprint (averaging under 6% CPU utilization and 62 MB of RAM during standard scans).
This native portability allows you to spin up VORTEX inside staging servers, auditing workstations, or ephemeral Docker containers without complex setup overhead.

🔌 Native CI/CD Integration

One of the greatest friction points in DevSecOps is integrating security testing without turning pipelines into delivery bottlenecks. VORTEX outputs native SARIF 2.1.0 reports, enabling strict security gatekeeping across popular developer platforms.

GitHub Actions (.github/workflows/security.yml)

YAML
name: VORTEX Security Assessment

on:
  push:
  pull_request:

jobs:
  vortex:
    name: VORTEX Security Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install VORTEX
        run: |
          curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash

      - name: Run VORTEX
        run: |
          vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: /opt/vortex/reporte/reporte.sarif

GitLab CI (.gitlab-ci.yml)

YAML
vortex_security:
  stage: test

  script:
    - curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | bash
    - vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

  artifacts:
    when: always
    paths:
      - /opt/vortex/reporte/

Azure DevOps (azure-pipelines.yml)

YAML
steps:
- checkout: self

- script: |
    curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash
    vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif
  displayName: 'VORTEX Security Assessment'

- task: PublishBuildArtifacts@v4
  inputs:
    pathToPublish: '/opt/vortex/reporte'
    artifactName: 'VORTEX-Reports'
  displayName: 'Publish VORTEX Reports'

⚡ Quick Installation

Want to test the VORTEX Community Edition? No credit card is required to get started.

Install on Ubuntu / Debian

curl -sSL -o install.sh [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh)
chmod +x install.sh
sudo ./install.sh

Run Your First Local Assessment

vortex --local --port [PORT_NUMBER]

🔗 Useful Links & Documentation

Official Website & Docs: zerodayslab.co/docs
GitHub Repository: github.com/matarturo/vortex

Conclusion & Call to Action

VORTEX was built to bridge the gap between fast-paced modern software development and offensive security requirements.

Clone the repository, test out the Community edition against your local SPAs, and drop a star on the repo or share your feedback to help drive the project forward. See you in the code!