TTechclick ⚡ XP 0% All lessons
Qualys · Vulnerability Management · WASInteractive · L1 / L2 / L3

Qualys WAS — Web Application Scanning from OWASP to API Security

Qualys WAS is the web-application scanning engine inside Qualys VMDR. It deep-crawls your apps, checks for OWASP Top 10 and OWASP API Top 10 flaws, handles authenticated sessions, imports Swagger/OpenAPI specs, sniffs for injected malware, and integrates with your WAF — all from the same cloud platform that tracks infrastructure CVEs.

📅 2026-06-20 · ⏱ 16 min · 4 infographics · live scan demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Master Qualys WAS in 2026: dynamic web-app scanning, OWASP Top 10, authenticated scans, Swagger/API testing, malware detection, and WAF integration — all inside Qualys VMDR.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

What WAS is

Dynamic scanning inside Qualys VMDR.

2

Auth & API coverage

Authenticated scans, Swagger, OWASP API.

3

Malware & WAF

Malware detection and WAF pass-through.

4

Reports & triage

Findings, severity, VMDR workflow.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Is Qualys WAS the same as Qualys VMDR's network scanner?

Answered in What WAS is.

2. How does WAS reach pages behind a login?

Answered in Auth & API coverage.

3. What must you add to your WAF to let WAS scan through it?

Answered in Malware & WAF.

Most engineers think…

Most people assume a vulnerability scanner that finds missing patches also covers web-application logic flaws. It does not — network scanners read banners and version strings; they cannot log in, crawl a JavaScript SPA or inject a payload into a form field.

Qualys WAS is a dynamic application security testing (DAST) engine. It drives a real browser crawler through your app, replays authenticated sessions, imports Swagger specs to test every documented API endpoint, and checks for OWASP Top 10 and OWASP API Top 10 issues — things a network scanner will never see. It also scans for injected malware in live page responses and integrates with WAFs so scan traffic is not silently blocked. Understanding what WAS can and cannot do is exactly what separates a strong Qualys interview answer from a weak one.

① What Qualys WAS actually is — dynamic scanning inside VMDR

Qualys WAS is the web application scanning module inside Qualys VMDR. Where the VMDR asset scanner identifies missing patches and network-level CVEs by reading service banners and version strings, WAS is a DAST engine: it sends real HTTP requests to a running application, crawls links and forms, injects payloads, and observes the response. That means it can find OWASP Top 10 issues — SQL injection, XSS, broken authentication, sensitive data exposure — that never appear in a CVE feed.

WAS runs from the Qualys cloud, so there is nothing to install on the app server. You point it at a URL, configure a scan profile (light, thorough, or custom), and it does the crawling. Findings land in the VMDR unified dashboard alongside infrastructure CVEs, letting you apply TruRisk scoring across both attack surfaces in one view.

Figure 1 — WAS scan lifecycle — discover to remediate
Every Qualys WAS scan follows the same five-stage loop, from discovery through to a tracked remediation ticket in VMDR.WAS scan lifecycle — discover to remediateCrawlspider links &formsAuthenticatereplay login sessionTestinject OWASP payloadsDetectscore findings by QIDRemediateticket in VMDRdashboard
Every Qualys WAS scan follows the same five-stage loop, from discovery through to a tracked remediation ticket in VMDR.
DAST vs network scan — a clean interview line

When asked how WAS differs from VMDR infrastructure scanning, say: 'VMDR reads banners and version strings to find known CVEs; WAS is a DAST engine that crawls, authenticates, and injects payloads to find logic flaws like XSS and SQL injection that never appear in a CVE feed.' That one sentence separates you from 90% of candidates.

Quick check · Q1 of 10 · Understand

What is the fundamental difference between Qualys VMDR network scanning and Qualys WAS?

Correct: a. Network scanning reads service versions and maps known CVEs. WAS is a DAST engine: it crawls, authenticates, injects OWASP payloads, and finds logic flaws a network scan never sees.
👉 So far: Qualys WAS is a DAST engine inside VMDR — it crawls, injects payloads, and finds OWASP logic flaws that network CVE scanning cannot see.

② Authenticated scans & API coverage — reaching everything WAS can reach

Unauthenticated scanning only sees the public face of your app. The real attack surface is behind the login. WAS handles this through authenticated scans: you store credentials or record a Selenium-style login sequence, and WAS replays the session for every crawl. Cookies and tokens are refreshed automatically so the scan does not time out mid-way through a large app.

Swagger / OpenAPI import

REST APIs are often not discoverable by crawling alone — endpoints only appear in documentation. WAS lets you upload a Swagger/OpenAPI file (JSON or YAML, OpenAPI v2 or v3). WAS parses the spec and generates test cases for every documented endpoint, checking for the OWASP API Top 10 — broken object-level authorisation, excessive data exposure, improper rate limiting and more — using over 200 prebuilt signatures. This is the only reliable way to achieve full API coverage when endpoints are not linked from any UI page.

Figure 2 — WAS coverage layers
WAS builds complete coverage by stacking unauthenticated crawl, authenticated session, and imported API spec.WAS coverage layersAPI endpointsSwagger/OpenAPI import for undiscoverable routesAuth pagesstored credentials or recorded login replayPublic surfaceunauthenticated crawl of all linked pages
WAS builds complete coverage by stacking unauthenticated crawl, authenticated session, and imported API spec.
🔐
Authenticated scan
tap to flip

WAS stores credentials or replays a recorded login sequence, then keeps cookies and tokens refreshed throughout the crawl — so it reaches every protected page.

📄
Swagger/OpenAPI import
tap to flip

Upload a JSON or YAML spec and WAS generates test cases for every documented endpoint, covering OWASP API Top 10 issues that a crawler alone would miss.

🦠
Web malware detection
tap to flip

WAS fetches live page responses and checks them against deep-learning signatures for injected scripts, skimmers, and redirects — included with every WAS subscription.

🛡️
WAF integration
tap to flip

Allowlist the Qualys scanner IP on your WAF, and optionally configure header injection so the WAF passes scan traffic without inspection while still blocking real attacks.

Quick check · Q2 of 10 · Apply

Your app has 50 REST API endpoints that are not linked from any UI page. How do you make WAS test all of them?

Correct: b. Endpoints not reachable by crawling require an OpenAPI/Swagger import. WAS parses the spec and generates test cases for all documented routes, covering OWASP API Top 10 checks.
👉 So far: Authenticated scans + Swagger/OpenAPI import = full coverage: login-protected pages and every documented API endpoint tested for OWASP API Top 10.

③ Malware detection & WAF integration — the two runtime concerns

A web application can be exploited and have malware injected into its response pages — a script tag that loads a skimmer or a redirect to a phishing site. Qualys WAS includes web malware detection as part of every subscription. The scanner fetches live page responses and checks them against deep-learning-based signatures. When malware is found it appears as a finding in the same dashboard as OWASP findings, so there is one place to triage both vulnerability and compromise signals.

WAF integration — scanning without being blocked

If a WAF sits in front of your app, aggressive scan traffic can look like an attack and get blocked. WAS handles this two ways: first, add the Qualys scanner IP range to the WAF allowlist; second, configure header injection — WAS adds a unique custom HTTP header to every scan request, and the WAF is told to pass traffic bearing that header without inspection. This keeps the WAF blocking real attacks while letting scan traffic through unfiltered.

Figure 3 — WAS module connections
Qualys WAS sits at the centre, feeding findings to VMDR and receiving input from WAF, malware feeds, and API specs.WAS module connectionsQualys WASDAST engineOWASP Top 10OWASP API Top 10Malware detectWAF passthroughSwagger importVMDR dashboard
Qualys WAS sits at the centre, feeding findings to VMDR and receiving input from WAF, malware feeds, and API specs.
Forgetting WAF integration before a scan

Running WAS against an app protected by a WAF without allowlisting scanner IPs or configuring header injection produces misleadingly clean reports — the WAF silently drops all the attack payloads and WAS sees clean responses everywhere. Always confirm WAF pass-through before interpreting zero findings as 'secure'.

▶ Watch a WAS scan catch a reflected XSS through a WAF

A real end-to-end authenticated scan flow. Press Play for the healthy path, then Break it to see the most common scan failure.

① AuthenticateWAS replays the stored login sequence, gets a session cookie, and begins crawling protected pages of the target app.
② WAF passthroughEvery request carries the custom scan header. The WAF matches the header and forwards requests unblocked to the origin.
③ Payload injectWAS injects an XSS payload into a search parameter on the account dashboard page and reads the raw HTTP response.
④ Finding + reportThe payload is reflected unescaped — WAS raises a QID tagged OWASP A03/XSS, captures the proof response, and posts the finding to the VMDR dashboard.
Press Play to step through the healthy authenticated-scan path. Then press Break it.
Quick check · Q3 of 10 · Remember

Which two mechanisms does Qualys WAS use to ensure scan traffic passes through a WAF unblocked?

Correct: d. WAS uses two WAF integration methods: add Qualys scanner IPs to the WAF allowlist, and configure a unique custom header that the WAF is told to pass without inspection.
👉 So far: Web malware detection is included in every WAS subscription. WAF pass-through uses IP allowlisting plus header injection — without it, scan results are meaningless.

④ Reports & triage — reading a WAS finding and acting on it

Every WAS finding has a QID (Qualys vulnerability ID), a severity (1–5), a URL, the exact parameter or header that was tested, the payload that triggered the response, and a proof screenshot where relevant. Findings are tagged to OWASP Top 10 or OWASP API Top 10 categories so you can export compliance-ready reports directly. The scan report also surfaces sensitive content exposure — credit-card patterns, SSNs, or private keys found in page responses.

Because WAS findings land in the VMDR unified dashboard, you can combine them with infrastructure CVEs and apply TruRisk-based prioritisation across both. A critical XSS on a public-facing checkout page and a critical OS CVE on the same host appear together, letting you decide which to patch first based on real business risk rather than raw CVSS. From the dashboard you can assign findings to a ticket, set a due date, and track remediation status — the same workflow as for network CVEs.

Figure 4 — Network scanner vs Qualys WAS
Network CVE scanning and WAS are complementary — they find completely different classes of issue.Network scanner vs Qualys WASNetwork / CVE scannerReads service banners &Maps known CVEs (NVD / QIDs)No login, no crawl, no payloadFinds unpatched softwareQualys WAS (DAST)Drives a real HTTP crawlerInjects OWASP payloadsLogs in, imports API specsFinds logic flaws & malware
Network CVE scanning and WAS are complementary — they find completely different classes of issue.

Priya at a Pune fintech faces this

WAS scans the payment portal and returns zero findings. The security team is sceptical — the app clearly has a login and dozens of API endpoints that no one has tested.

Likely cause

The scan was run without authentication and without a Swagger import, so WAS only saw the public login page and could not reach any protected functionality or undocumented API routes.

Diagnosis

Check the scan report — most pages return HTTP 302 redirects to the login page, and API endpoint count in the report is zero. The crawl never got past the login wall.

WAS ▸ Scan Configuration ▸ Authentication + Web App ▸ API Assets
Fix

Configure an authenticated scan using stored credentials or a recorded login sequence. Upload the OpenAPI v3 spec for the payment API. Re-run the scan — WAS will now crawl all 50+ protected pages and test all documented API endpoints for OWASP Top 10 and OWASP API Top 10 flaws.

Verify

The new report shows findings across authenticated pages and API endpoints, including a reflected XSS on the statement download parameter and an excessive data exposure issue on a user-profile API route.

Check OWASP tagging in every report

Every WAS finding has an OWASP category tag. Before closing a finding, verify the OWASP classification matches the actual issue: an A01 Broken Access Control finding means the endpoint returned data it should not; an A03 Injection finding means a parameter accepted a payload. The category tells you where in the code to look, not just that something is wrong.

Quick check · Q4 of 10 · Analyse

A WAS scan reports a QID tagged as OWASP A03 (Injection). What does this tell you about the finding?

Correct: b. OWASP A03 Injection covers SQL injection, command injection, and similar flaws where untrusted input is interpreted as a command. WAS detected this by injecting payloads and observing the response — not by reading a CVE feed.
👉 So far: WAS findings carry QIDs, OWASP tags, and proof payloads. They land in the VMDR dashboard alongside CVEs for unified TruRisk prioritisation and remediation tracking.

🤖 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.

Q5 · Remember

What type of scanning does Qualys WAS perform?

Correct: c. WAS is a DAST engine: it sends real HTTP requests, crawls the running application, and injects payloads to observe how the app responds — finding logic flaws a static or network scan cannot.
Q6 · Understand

Why does an unauthenticated WAS scan miss most findings on a SaaS app with a login?

Correct: c. Without authentication, WAS hits the login redirect for every protected URL and never crawls the actual application. Authenticated scans replay a session to reach protected pages.
Q7 · Apply

A WAF is blocking all Qualys WAS scan payloads. Which configuration change fixes this without disabling the WAF?

Correct: d. IP allowlisting and header injection are the two official WAS WAF integration methods. They let the WAF continue blocking real attacks while passing authenticated scan traffic through to origin.
Q8 · Understand

Which Qualys WAS feature detects injected card skimmers or malicious redirect scripts on a live web page?

Correct: b. Web malware detection fetches live page responses and checks them against deep-learning-based signatures. It finds injected malware such as skimmers and redirect scripts — not covered by OWASP vulnerability payloads.
Q9 · Analyse

WAS reports a finding tagged OWASP A01 (Broken Access Control) on an API endpoint. What is the most likely issue?

Correct: a. OWASP A01 Broken Access Control means the application does not properly enforce who can access what — a classic example is an API that returns another user's records when the object ID is changed in the request.
Q10 · Evaluate

A WAS scan of your e-commerce checkout returns zero findings. What is the FIRST thing to verify before concluding the app is secure?

Correct: b. Zero findings most often means the scan never reached the application (WAF blocking payloads) or never logged in (unauthenticated scan missing the checkout flow). Verify WAF integration and authentication before concluding there are no issues.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why can Qualys WAS find issues that a CVE/network scanner cannot? Then compare with the expert version.

Expert version: A network scanner reads service banners and version strings to match known CVEs — it never sends a payload into an application or observes how the app processes input. Qualys WAS is a DAST engine: it authenticates, crawls, and injects payloads (XSS, SQL injection, etc.) into forms, parameters and API endpoints, then observes the response. That means it can catch logic flaws like reflected XSS on a search field or broken object-level authorisation on an API route, which have no CVE and would never appear in a network scan report.

🗣 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)
Testing a running application by sending real HTTP requests and observing responses — finds logic flaws like XSS and SQL injection that static or network scans miss.
Authenticated scan
A WAS scan mode that stores credentials or replays a recorded login, then crawls all pages the logged-in user can reach.
Swagger / OpenAPI import
Uploading a JSON or YAML API spec so WAS generates test cases for every documented endpoint, covering routes a crawler cannot discover.
OWASP Top 10
The ten most critical web-application security risks (e.g. Injection, Broken Access Control, XSS) maintained by OWASP and mapped to every WAS finding.
OWASP API Top 10
A parallel list of the ten most critical API security risks (e.g. Broken Object Level Authorisation, Excessive Data Exposure) tested by WAS via prebuilt signatures.
Web malware detection
WAS fetching live page responses and checking them against deep-learning signatures to find injected scripts, skimmers, and malicious redirects.
WAF header injection
Configuring WAS to add a unique HTTP header to scan requests so the WAF can identify and pass scan traffic without blocking payloads.
QID (Qualys Vulnerability ID)
A unique identifier assigned to each type of finding in Qualys, used to track, categorise, and report vulnerabilities consistently across VMDR and WAS.
TruRisk
Qualys risk-scoring model that combines CVSS, threat intelligence, and asset context to prioritise both CVEs and WAS findings by real business risk.

📚 Sources

  1. Qualys — Web Application Scanning datasheet. qualys.com/docs/web-application-scanning-datasheet.pdf
  2. Qualys Docs — WAS documentation (authenticated scans, API assets, Swagger import). docs.qualys.com/en/was/latest/
  3. Qualys Blog — Secure your APIs with AI-powered API security in Qualys WAS. blog.qualys.com (July 2024)
  4. Qualys Support — API Testing with Swagger / OpenAPI in WAS. success.qualys.com/support/s/article/000006252
  5. Qualys Docs — WAS release notes: API security and OpenAPI spec scanning. docs.qualys.com/en/was/release-notes/
  6. Security MEA — Qualys launches AI-powered WAS with API security. securitymea.com (July 2024)

What's next?

Covered WAS? Next, go deep on Qualys VMDR's asset discovery and QID tagging — how every CVE is fingerprinted, prioritised with TruRisk, and pushed to a patch workflow.