AI
The DAST Vendor Promise vs Real-World Scan Results
Vendors sell the same pitch: pay, point, click, secure. One scan covers compliance. Sleep well. What comes back is self-signed certificates in a dev environment, a few missing security headers, and zero critical findings. Mission accomplished.
Albert-Tóth had manually exploited HTML injection, XSS, SQL injection, and broken authorization in the same app. The tool returned nothing. The question that framed everything that followed: what did the scanner actually test?
Use Case 1: How an SPA with Non-RESTful JSON Breaks a Desktop DAST Tool
The target was a fintech serving Fortune 500 clients: an AngularJS SPA backed by a non-RESTful JSON API where routing lived entirely on the front end. A desktop DAST tool at $8,000 per seat per year authenticated successfully, then stopped at the landing page. It could not crawl a single route. For four hours it brute-forced directories, hitting paths like /admin, /config, and /backup against a Java back end that had none of them. The app logs made it visible. The scan results did not.
Use Case 1 Solution: Custom Burp Plugin Pipeline with Code-Coverage Gating
They ditched the scanner. AST-based code parsing produced custom API descriptors with JSON structures, enum permutations, and payload positions. A Burp Suite plugin consumed those descriptors and fired thousands of targeted mini-scans, each about a minute long. A Maven plugin launched Burp, loaded extensions, and listened on a socket for results — he walked through the Use case 1 automation flow diagram walkthrough (11:04) live. Integration test data stayed in the database so the scan could reach guarded code paths. JaCoCo bytecode instrumentation tracked which lines the scanner hit. The outcome: CI/CD scans, pipeline breaks on high findings, 20–25 times cheaper.
Use Case 2: Enterprise Cloud DAST Fails on Incremental Authentication
A Fortune 500 client was paying up to a million dollars per year for a cloud DAST platform. The app had over 1,000 REST endpoints and Okta-style incremental authentication: username, click next, password, click next. The scanner’s built-in form auth could not handle the sequence. Manually injecting session tokens didn’t help. After four hours parsing a 70,000-line OpenAPI spec, the tool sent either security headers or cookies, never both, returning 401s each time. No application logs, no scanner logs, no error details. The vendor’s professional services team took three weeks to schedule a call with the wrong person on it.
Use Case 2 Solution: Reverse Proxy Middleware for Auth and Full Visibility
The fix runs through three layers. Playwright handles the Okta multi-step login and extracts session cookies and bearer tokens. Because the enterprise scanner blocks both cookies and custom headers simultaneously, the middleware encodes cookies as a Base64 custom header, then decodes and re-injects them before forwarding each request to a team-controlled AWS Lambda subdomain. The Lambda logs every request and response to a database. He showed the live demo: middleware logs authenticated scan requests (24:55). The database confirmed the session ID, referer header, bearer token, and cookies all arrived correctly. The team wired the flow into CI/CD, operationalizing it across the top 10 repositories of a client with over 2,000.
Lessons Learned and DAST Tool Procurement Checklist
DAST tools fail in predictable patterns: complex authentication (Okta, token-based, certificate-based, incremental flows), modern frontend architectures (SPAs, GraphQL, non-standard JSON schemas), and anything that produces silent failures. A clean report means nothing if the scanner never authenticated. Before buying, run a proof-of-concept against your own applications, test your exact authentication flow, verify coverage, check CI/CD compatibility, and calculate the full cost of ownership: licensing plus integration work plus staffing.
“don’t let the brochure dictate what’s possible when tools fall short get creative” — István Albert-Tóth
Security is not about buying solutions.
Q&A
What was the name of the expensive enterprise tool? He declined to name the vendor on stage, telling the questioner to bribe him after the presentation. ▶ 35:12
How long did it take to get results for both use cases? Use case 1 took one to one-and-a-half months with one or two people sharing it alongside other priorities; use case 2 took about two-and-a-half weeks to reverse-engineer the requests and build the solution. ▶ 35:34
Do you have principles to reduce false positives in DAST results? He said there is no short answer: out-of-the-box tools give you no control, but generating your own API descriptors (as in use case 1) lets you tell the scanner exactly which parameters to test, and cross-correlating with IAST or SAST tools is a direction he has not implemented yet because he needs a client willing to fund it. ▶ 39:15
How exactly did you use the integration tests to improve scan quality, and how did you handle cleanup of dummy data between scans? He ran integration tests solely to seed test data in the application and commented out the cleanup step so that data persisted for the DAST scan; for post-scan cleanup he simply nukes the whole database and rebuilds from scratch. ▶ 41:15
Notable Quotes
And yeah, silent failures make it look István Albert-Tóth · ▶ 29:45
don’t let the brochure dictate what’s István Albert-Tóth · ▶ 34:25
The best security engineers in my István Albert-Tóth · ▶ 34:33
It’s rather about solving problems. István Albert-Tóth · ▶ 34:37
Key Takeaways
- Validate what your DAST tool actually tested before trusting its clean report.
- When a tool blocks you, become the middleware—a reverse proxy gives you control of both sides.
- Instrument your apps for security coverage the same way you measure unit-test code coverage.
About the Speaker
István Albert-Tóth
István has over a decade of experience in cybersecurity and software development, currently serving as the DevSecOps and Product Development Director at VerSprite. Drawing on his diverse background from enterprise-level projects to startup ventures and consultancy, István applies his insights to address pain points across the cybersecurity landscape. He leads consultancy efforts and oversees the development of both a Threat Modeling and a Cloud Security Posture Management SaaS platform. István is also the maintainer of the OWASP CSRFGuard project and has notable contributions to multiple open-source security automation tools, especially in the areas of vulnerability scanning and attack surface mapping.