Most engineers think…
Most engineers hear 'web app scanner' and picture a tool that just fires SQLi payloads at a login form. That mental model is far too narrow — and it will hurt you in a Tenable interview.
Tenable WAS is a full DAST pipeline: it first crawls the running application to build a site map of every page, link, form, and API endpoint; then it tests each one systematically. It authenticates into protected areas (OAuth, form login, Selenium recording), tests REST/GraphQL/SOAP APIs, maps findings to OWASP Top 10, and surfaces results directly in Tenable Vulnerability Management so you remediate web-app and infra risk in one place. Understanding that end-to-end pipeline is what separates operators who tune scans well from those who flood the queue with false positives.
① How Tenable WAS crawls a running application
Tenable Web App Scanning is a dynamic application security testing (DAST) tool — it interacts with your live, running application through the front end, exactly the way a real browser or attacker would. It never reads source code. Because it drives the actual application, it catches runtime vulnerabilities that static analysis misses.
The first thing WAS does on every scan is crawl: it follows links, fills forms, and explores navigation to build a site map. Every page, link, form, and API endpoint in that map becomes a test target in the next phase. Scope is tunable: maximum crawl depth, domain restrictions, URL include/exclude patterns, and rate limiting are all configurable, so you avoid hammering staging environments or drifting out of scope.
For applications built on modern single-page app (SPA) frameworks — Angular, React, Vue — WAS includes SPA-aware crawling. For highly complex flows, you can train the crawler by recording a Selenium session that walks the scanner through the tricky path, then replaying that recording as part of the scan configuration.
Before running a full WAS scan, set crawl depth limits, domain restrictions, and URL exclusion patterns. Scanning without scope control can drift into third-party domains, overload a staging server, or generate hundreds of irrelevant findings from unrelated subdomains.
Why is Tenable WAS described as a DAST tool rather than a SAST tool?
② OWASP Top 10 coverage — what WAS actually tests for
Once the site map is complete, WAS interrogates each target for vulnerabilities in two categories: flaws in the application's custom code (XSS, SQL injection, command injection, insecure direct object references, and so on) and known-vulnerable third-party components embedded in the application (outdated libraries and frameworks with published CVEs).
OWASP Top 10 classes WAS covers
- A01 Broken Access Control — forced browsing, privilege escalation probes
- A02 Cryptographic Failures — weak TLS, expired certs, sensitive data in transit
- A03 Injection — SQL, command, LDAP, XPath injection payloads
- A07 XSS — reflected, stored and DOM-based cross-site scripting
- A06 Vulnerable Components — outdated libraries with known CVEs
- A05 Security Misconfiguration — default credentials, exposed debug endpoints
A rapid scan template is also available for common hygiene checks — SSL/TLS certificate issues, HTTP security headers — that can complete in under two minutes, useful for CI/CD pipeline gates.
Drives the live application like a browser, following links and filling forms to build a complete site map before any testing begins.
WAS logs in using form credentials, OAuth tokens, or a Selenium recording so it can test protected pages and APIs behind the login wall.
Automatically discovers REST endpoints and accepts OpenAPI/Swagger, GraphQL, and SOAP specs to test the full API attack surface for injection and auth flaws.
WAS findings flow into Tenable Vulnerability Management with VPR scores alongside infra/cloud findings, so the whole team remediates from one queue.
Which OWASP Top 10 category covers cross-site scripting (XSS)?
③ Authenticated scans and API security testing
Unauthenticated scans miss everything behind a login — which is most of the interesting attack surface in a real SaaS application. Tenable WAS solves this with authenticated scan configuration. You can supply a form-based username and password, configure an OAuth 2.0 token flow, provide API keys directly, or record a Selenium session that performs the login sequence — WAS replays the session to enter the authenticated area before crawling begins.
For API security, WAS automatically discovers REST endpoints, infers parameter types, constructs payloads, and tests for injection, authentication bypass, and data exposure. You can also import an OpenAPI / Swagger specification to guide the API scan, giving the tool explicit endpoint definitions rather than relying entirely on crawl discovery. GraphQL schemas and SOAP WSDLs are also supported, so WAS can probe modern and legacy API surfaces with equal depth.
The interview point: combining authenticated scanning with API specification import means WAS tests the full attack surface — not just the public-facing pages, but the authenticated SaaS screens and every API route the specification documents.
Even apps with public landing pages have authenticated attack surfaces — account settings, API keys, transaction history, admin panels. Skipping authentication means your WAS scan is only testing the tip of the iceberg. Always configure auth for the realistic test.
▶ Watch WAS find an XSS flaw behind a login
An end-to-end authenticated DAST scan — from login to finding. Press Play for the healthy detection path, then Break it to see the classic miss.
A developer wants WAS to test all documented API routes, not just what the crawler discovers. What should they provide?
④ Findings, severity and the Tenable platform
WAS does not live in isolation. Results flow directly into Tenable Vulnerability Management (formerly Tenable.io), where web-app findings appear alongside network and cloud findings in a single remediation queue. Each finding carries a VPR (Vulnerability Priority Rating) and maps to a CVE or CWE so security and dev teams share the same language.
A finding record shows the URL, parameter, proof-of-concept payload, HTTP request/response, OWASP category, and remediation guidance — enough for a developer to reproduce and fix the issue without back-and-forth with the security team. Findings can be routed to ticketing systems (Jira, ServiceNow) via integrations, closing the loop from discovery to fix.
Scan configuration best practices
Start new scans in audit mode or with a low-rate configuration to measure false-positive volume, especially on staging. Tune scope and exclude patterns, then promote to full-rate. Use the rapid template for CI/CD gates and the full DAST template for scheduled deep scans. Keep API specification files updated — a stale Swagger import means new endpoints are missed.
Priya at a Pune fintech company faces this
The WAS scan of the company's customer portal returns only a handful of low-severity findings, but the dev team suspects there are injection flaws in the transaction history pages that require login.
The scan is running unauthenticated — WAS never gets past the login page, so it only tests the public-facing pages and misses all authenticated routes.
Check the scan configuration: Authentication is set to None. The site map in the scan results only shows the login page and public marketing pages — zero authenticated paths.
Tenable VM ▸ Web App Scanning ▸ Scan Configuration ▸ AuthenticationAdd a form-based login configuration with test credentials (or a Selenium recording if MFA is involved). Re-run the scan and import the OpenAPI spec to also cover API endpoints explicitly.
The new scan site map now includes the dashboard, transaction history, and API routes. Findings include two SQL injection vulnerabilities in the transaction filter parameters — exactly what the dev team suspected.
Before trusting a 'clean' WAS result, open the scan's site map and confirm it includes the authenticated paths and API routes you expected. A zero-finding scan from a scan that never crawled past the login page is not a clean app — it is a misconfigured scan.
What is the main advantage of running WAS with authentication configured versus an unauthenticated scan?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the first thing Tenable WAS does when a scan starts, and why does it matter? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- DAST
- Dynamic Application Security Testing — tests a running application through the front end, the way a real attacker would, without access to source code.
- Site map
- The inventory of every URL, form, link, and API endpoint discovered by the WAS crawler — the input list for the probe phase.
- OWASP Top 10
- The Open Web Application Security Project's ranked list of the ten most critical web application security risk categories, including injection, XSS, and broken access control.
- Authenticated scan
- A WAS scan configured with login credentials (form, OAuth, or Selenium recording) so the crawler can reach and test pages behind the authentication wall.
- OpenAPI / Swagger spec
- A machine-readable API specification that WAS can import to get explicit endpoint definitions, parameter types, and operation details for comprehensive API testing.
- VPR
- Vulnerability Priority Rating — Tenable's unified severity score combining CVSS with threat intelligence (exploit availability, active exploitation) to prioritise what to fix first.
- Rapid scan template
- A WAS scan preset that checks SSL/TLS certificates and common HTTP security headers in under two minutes — suitable for CI/CD pipeline gates.
- XSS (Cross-Site Scripting)
- An injection vulnerability (OWASP A07) where an attacker injects malicious scripts into web pages viewed by other users — reflected, stored, or DOM-based.
📚 Sources
- Tenable — Tenable Web App Scanning product page. tenable.com/products/web-app-scanning
- Tenable Docs — Tenable Web App Scanning User Guide (May 2026). docs.tenable.com/web-app-scanning
- Tenable Docs — Getting Started with Tenable Web App Scanning. docs.tenable.com/web-app-scanning/Content/WAS/GettingStarted/GetStarted.htm
- Tenable — Comprehensive DAST Guide: Web App Vulnerability Scanning. tenable.com/whitepapers/getting-started-with-web-application-scanning
- Splunk Lantern — Identifying web application vulnerabilities with Tenable WAS. lantern.splunk.com/Security_Use_Cases/Threat_Investigation/Identifying_web_application_vulnerabilities_with_Tenable_WAS
- Cyber Risk Leaders — Tenable's Web Application and API Scanning. cyberriskleaders.com/tenables-web-application-and-api-scanning
What's next?
Got WAS? Next, explore Tenable Nessus and network-based vulnerability scanning to see how infra findings and web-app findings unite in Tenable One.