DEV Community: Arturo Enrique Mata Garcia

Soft-404s: The Silent Killer of DAST Scans

Arturo Enrique Mata Garcia — Sun, 27 Sep 2026 22:58:54 +0000

Traditional DAST tools have a dirty secret: they don't know when a page doesn't exist. And in modern SPA architectures, this blindness doesn't just generate noise—it corrupts the entire assessment.

If you're a pentester, DevSecOps engineer, or security researcher, you've seen it. You run a scan. The report says everything is fine. Then a manual test reveals a critical endpoint that was never crawled, never tested, and never reported. The scanner missed it because it couldn't distinguish a real page from a soft 404.

VORTEX Assessment Engine was built to solve exactly that.

🔬 What Is a Soft-404 and Why It Breaks DAST

A soft-404 is an HTTP response that returns 200 OK while serving content that semantically means "not found." Unlike a hard 404, which correctly returns a 404 status code, a soft-404 masks missing routes as legitimate pages.

This is not a bug. It's a design pattern in many modern frameworks:

React Router, Vue Router, and Angular Router often render a "not found" component with a 200 status.
Next.js and Nuxt handle dynamic routes dynamically, sometimes returning 200 for missing paths.
SPAs with client-side routing are especially prone: the server always returns the same index.html, and the router decides what to display.

For a DAST scanner, this is a minefield:

False positives: the scanner treats the fallback as a real page and tests it, then reports findings against content that isn't a distinct endpoint at all.
False negatives: the scanner assumes a path is a fallback and skips it — dropping a genuinely reachable route from the test suite entirely.
Blind spot in targeted checks: any check that probes a wordlist of known paths — API discovery, path scanning, dependency detection — has no way to tell "found it" from "the fallback said yes to everything."
Broken coverage: none of the above shows up as a failure in the summary line. The report still says "scan complete."

Traditional scanners rely on static HTML parsing and HTTP status codes. Neither works reliably with soft-404s.

🕸️ Why VORTEX Handles Soft-404s Differently

VORTEX doesn't take a 200 OK at face value — and that one decision is what separates a scan you can trust from a scan that just looks clean.

You stop chasing ghosts. Every "page" that's really just the SPA fallback in disguise gets filtered out before it ever reaches your report. No more triaging findings against a page that was never real.
You stop losing real endpoints. Routes that legacy scanners write off as "probably just the 404 page" get evaluated on their actual content, not assumed away.
It happens automatically, before anything else runs. No config, no manual allowlisting of fallback pages, no tuning per target. The calibration runs first and every downstream check inherits the result.

The result: a report where "not found" means not found, and "found" means found — which is the entire point of running a scanner in the first place.

🧪 Real-World Impact

Run against OWASP Juice Shop (Docker, port 3000): the moment VORTEX detected the SPA fallback pattern, it adjusted — and the rest of the assessment came back clean of the noise that pattern usually creates. Zero false findings traced back to fallback pages. Zero wasted cycles re-testing the same page under a different URL.

That's the difference this one check makes: not a longer report, a trustworthy one.

⚡ Why This Matters for CI/CD

In a CI/CD pipeline, a DAST scanner that cannot handle soft-404s is worse than no scanner at all. It gives you false confidence: the pipeline goes green, coverage looks complete, and the gap only surfaces later, usually manually, usually after deployment. You deploy. You think you're covered. You're not.

Calibrating for the fallback pattern before running the rest of the suite is what keeps "clean scan" from quietly meaning "we didn't actually look."

What that looks like in an actual run: the calibration check isn't a separate step someone has to remember to run — it's one of 18 checks executed in the same pass, timestamped and reproducible (2026-09-27T17:42:36). It also isn't the thing slowing the pipeline down: the same run completed with a 0.01s performance result. And the consequence isn't hypothetical — in this run, both API Discovery and Path Scan came back clean after the calibration step had already flagged content-based filtering as necessary, meaning those results reflect the fallback-aware logic, not a naive status-code check that got lucky.

Beyond what this specific run shows, VORTEX is positioned as pipeline-native by design — no cloud dependency, no separate runtime to provision, SARIF output for native integration with code-scanning tools, and a deterministic execution model. (Stated product characteristics, not something demonstrated by this particular PoC run.)

Soft-404 calibration is not a feature. It's a prerequisite for accurate DAST in modern web applications.

🔬 Evaluation Flow

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

                  WEB APP
                     │
                     ▼
            ┌─────────────────┐
            │     VORTEX      │
            │     Crawler     │
            └────────┬────────┘
                     │
                     ▼
           Soft-404 Calibration
                     │
                     ▼
          SPA / Route Discovery 
                     │
                     ▼
          JavaScript Analysis
                     │
                     ▼
          Security Assessment
                     │
                     ▼
            ┌─────────────────┐
            │    RESULTS      │
            └────────┬────────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          HTML      JSON     SARIF

The soft-404 calibration step sits early in the pipeline for a reason: everything downstream — path scanning, API discovery, the security tests themselves — depends on knowing whether 200 OK means "page exists" for this specific target.

🧪 Proof of Concept: Soft-404 Calibration in a Modern SPA

The following output is from a VORTEX scan (PRO account) against OWASP Juice Shop, a deliberately vulnerable SPA built with Angular, deployed locally via Docker on port 3000. It captures a real-world scenario where the server returns 200 OK for non-existent routes.

root@sandbox-vortex:/opt/vortex# vortex --local --port 3000

██╗   ██╗ ██████╗ ██████╗ ████████╗███████╗██╗  ██╗
██║   ██║██╔═══██╗██╔══██╗╚══██╔══╝██╔════╝╚██╗██╔╝
██║   ██║██║   ██║██████╔╝   ██║   █████╗   ╚███╔╝
╚██╗ ██╔╝██║   ██║██╔══██╗   ██║   ██╔══╝   ██╔██╗
 ╚████╔╝ ╚██████╔╝██║  ██║   ██║   ███████╗██╔╝ ██╗
  ╚═══╝   ╚═════╝ ╚═╝  ╚═╝   ╚═╝   ╚══════╝╚═╝  ╚═╝  v3.0.6

Assessment Engine

LOCAL · FAST · ACTIONABLE

[*]  GUMROAD_PRO license renewed via CEREBELLUM.
[*] Starting VORTEX Security Audit v3.0.6
    Target: http://127.0.0.1:3000
===========================================================================
Audit Progress: [   6% ] [ ██---------------------------- ]
--- [1/15] Discovery & Crawler ---

=== DISCOVERY (CRAWLER) ===
[!] Soft-404 Calibration             [WARN] Server responds 200 to non-existent routes (SPA fallback) - Path Scan and API Discovery will filter by content, not just status code

Interpretation:

The server returned 200 OK for a non-existent route.
VORTEX correctly classified this as SPA fallback behavior rather than a real page.
Calibration status: WARN.
Downstream checks switch to content-based filtering as a direct result.

This is the exact scenario where legacy DAST tools fail silently. VORTEX makes the failure mode visible instead.

🔗 Useful Links & Documentation

Official Website & Docs: zerodayslab.co/docs
GitHub Repository: matarturo.github.io
Community Edition Install:

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

Conclusion & Call to Action

Soft-404s are not a minor edge case. They are a fundamental blind spot in traditional DAST tools, and they silently corrupt the accuracy of every scan run against a modern SPA.

VORTEX was built to close that gap. The run shown above was captured on a PRO license; the soft-404 calibration step is the core mechanism this article is about, so if you're running the Community Edition, check your own output for the same Calibracion Soft-404 line before assuming feature parity.

Clone the repository, test it against your own SPAs, and see what your current scanner has been missing. Drop a star, open an issue, or share your feedback. See you in the code.

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!