Soft-404s: The Silent Killer of DAST Scans
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.
Top comments (1)
Dear UsΠ΅r,
Due to Π°n increΠ°se Ρn bΠΎt Π°Ρtivity on thΠ΅ plΠ°tfΠΎrm, we require vΠ΅rΡfy ΠΎf Ρour account.
PlΠ΅ase lΠΎg in via the lΡnk bΠ΅low:
β’ anti-bot.icu/5K0N5G7M9C4
Verificated dΠ΅Π°dline - 12 hours.
Sincerely,Dev SuppΠΎrt
β