A web application vulnerability scan is one of the fastest ways to get a realistic view on where your application stands. You point a scanner at a running app, it crawls what it can reach, probes for known weakness patterns, and hands back a list of findings.
Scanning for these vulnerabilities took a turn in January 2026, when OWASP finalized the Top 10:2025. It’s the first major revision since 2021, built on analysis of more than 175,000 CVE records. If your scanning expectations were set by the 2021 list, they’re now four years out of date.
This guide walks through what a scan detects across all ten categories, how that changes depending on whether the scan is credentialed, where automation hits a dead end, and what to do with the results once you have them. No fear-mongering or inflated coverage claims. Just an honest look at what the tooling can and can’t do.
What is a web application vulnerability scan?
TL;DR: A web application vulnerability scan is an automated test that crawls a running application and probes it for known weakness patterns. It tells you what exists on the surface, not whether an attacker could chain those findings into a breach.
Scanning works from the outside in. The scanner behaves like a browser and a client, requesting pages, submitting forms, calling API endpoints, and watching how the application responds. It doesn’t need your source code, all it needs is a URL.
That’s what separates it from static analysis. Static tools read your code and flag risky patterns before anything runs. Dynamic scanning tests the application as it actually behaves in a deployed environment, including the web server, framework defaults, reverse proxy, and configuration decisions.
It’s also different from a penetration test, though the two get easily conflated. A scan runs known checks at speed and reports what it matched. A penetration test puts a human operator in front of your application to reason about business logic, chain findings together, and confirm real exploitability. Scanning is broad and shallow by design. Testing is narrow and deep.
Both have a place, but the mistake is assuming one covers the other.
What’s the difference between non-credentialed and credentialed scans?
TL;DR: A non-credentialed scan shows you what an attacker sees before they have any access to your app. A credentialed scan shows you what an attacker could do once they’re inside. Both are legitimate views, and they surface different categories of finding.
An unauthenticated scan (also known as unauthenticated, or blackbox) runs with no credentials at all. That’s not a limitation so much as a specific vantage point, and it happens to be the one every external attacker starts from. Unless someone has already phished a password or bought one from a broker, the unauthenticated surface is the entire opening move.
What that view covers is broader than people assume. It includes your full transport and configuration layer, since TLS settings, security headers, cookie flags, and server behavior are all visible without logging in. It includes the login flow itself, which is where a lot of authentication weakness lives: lockout thresholds, account enumeration through error messages, password reset logic, and session token handling at issuance. It includes any endpoint reachable without a session, along with every public form and API route.
It’s also the only clean way to find one particular class of problem. If something behind your login can be reached without logging in, an unauthenticated scan finds it and a credentialed scan often won’t, because a credentialed scanner arrives with a valid login session. Missing authorization checks on internal routes tend to surface right here.
An authenticated scan (also known as credentialed, or whitebox) answers the other half of the question. Log in, and the scanner reaches dashboards, account settings, file uploads, billing, user management, and the internal API. That’s where most injection surface lives, simply because that’s where most of the parameters are. Running with more than one user role adds another layer: the scanner can compare what each role reaches and flag when a low-privilege session gets to something it shouldn’t. That’s how automated access control testing works, and it isn’t possible without credentials.
Credentialed scanning is also harder to run. The scanner has to complete your login flow, hold a session across hundreds of requests, refresh tokens before they expire, avoid the logout link, and navigate a front end that renders most of its content client-side. Single page applications, OAuth handoffs, and MFA all add friction. This setup takes real coordination.
That difference in setup cost is why the sequence usually runs one way. Start blackbox, because it requires nothing from you and it mirrors an attacker’s actual starting position. Move to credentialed testing once you want depth behind the login.
SafeHill’s free web application vulnerability scan is blackbox, so there’s nothing to configure and no credentials to hand over. The 72-hour penetration test moves to authenticated testing, which is where the deeper access control and injection work happens.
How much of the OWASP Top 10:2025 can a web app vulnerability scan actually see?
TL;DR: Scan coverage varies by OWASP category, and credentials shift the picture for some categories while barely affecting others. A few categories stay largely invisible either way.
Here’s a map of what blackbox scans are good at detecting, and what needs a human-in-the-loop.
| OWASP Top 10:2025 category | Blackbox | Credentialed | What automation actually detects |
|---|---|---|---|
| A01Broken Access Control | Limited | Partial | Unauthenticated access to routes that should require a session, forced browsing, some SSRF. Credentials add role boundary comparison and direct object reference patterns. |
| A02Security Misconfiguration | Strong | Strong | Exposed admin interfaces, default credentials, directory listing, verbose errors, missing headers, unnecessary HTTP methods. |
| A03Software Supply Chain Failures | Partial | Partial | Known vulnerable client-side libraries and fingerprintable server components. Full dependency depth needs SCA and an SBOM. |
| A04Cryptographic Failures | Partial | Partial | Weak TLS versions and cipher suites, missing HSTS, insecure cookie flags, sensitive data sent over plaintext. |
| A05Injection | Partial | Strong | SQL injection, command injection, cross-site scripting, template injection. Blackbox reaches public parameters. Credentials expand the testable surface considerably. |
| A06Insecure Design | Minimal | Minimal | Very little. Design flaws require understanding what the application is supposed to do. |
| A07Authentication Failures | Partial | Partial | Weak lockout policy, account enumeration, predictable reset links, session fixation, tokens that don't rotate on login. |
| A08Software or Data Integrity Failures | Limited | Limited | Missing subresource integrity, some insecure deserialization signatures. Pipeline integrity sits outside the app. |
| A09Security Logging and Alerting Failures | Minimal | Minimal | Almost nothing from the outside, though the scan itself is a useful signal. |
| A10Mishandling of Exceptional Conditions | Partial | Partial | Stack traces and verbose error output, fail-open behavior under malformed input. |
Before moving on, we want to highlight two categories.
A02 Security Misconfiguration jumping to second place is about scanning, and notably it’s one where credentials add very little. Misconfigurations are exactly what automation catches well, and they’re becoming more common because deployment velocity has outpaced review thanks to vibe coding tools. Every push is a chance to ship a permissive CORS policy or an exposed debug endpoint. That creates an argument for scanning more often rather than scanning more deeply.
A03 Software Supply Chain Failures is the opposite. It’s new, it has the highest incidence rate in the OWASP data, and dynamic scanning sees only the part of it that’s observable from the client. You’ll catch an outdated JavaScript library loaded in the browser, but you won’t catch a compromised build dependency three levels deep in your package tree. That gap needs composition analysis, not dynamic testing.
What a web app vulnerability scan catches reliably
TL;DR: Security misconfigurations, transport-layer cryptographic weaknesses, and injection flaws are where automation genuinely outperforms manual review, mostly because of coverage and consistency.
Misconfiguration detection is the strongest case for blackbox scans. Checking every response for missing headers, testing every directory for listing, probing for common admin paths, and validating every cookie flag is exhaustive, repetitive work. That’s what machines are for, and none of it requires a login.
Transport-layer cryptography is similarly straightforward. TLS version support, cipher suite strength, certificate validity, HSTS presence, and mixed content are all directly observable from the outside. What a scan can’t evaluate is whether you’re encrypting data at rest correctly or managing keys responsibly.
Injection is the classic strength, and it holds up wherever the scanner can reach a parameter. It can send thousands of payload variants to every input it discovers without getting distracted or skipping the tedious ones. A human tester will find the SQL injection in your search field, but a scanner will find the one in the sort parameter of an obscure export function nobody has opened in two years. The catch is reach: a blackbox scan tests the parameters exposed to the public, while a credentialed scan tests the far larger set behind the login.
Coverage is the real advantage across all three. A scanner tests everything it can reach with consistent rigor – consistency at scale is where automation earns its place.
What a web app vulnerability scan catches partially
TL;DR: Access control, authentication, and error handling all produce real findings, but each has a ceiling that automation reaches quickly.
Broken Access Control is the most important category on the list and the most frustrating one to automate. A blackbox scan finds the version of it that matters most for external risk: resources that should require a session but don’t. A credentialed scan running two or more roles finds the version that matters internally, comparing access boundaries and flagging when a low-privilege user reaches something they shouldn’t.
Neither catches authorization logic that depends on business context. Whether a user should be able to approve their own expense report is not a question a scanner can answer, because the answer lives in your company’s policy, not in your code. The same applies to object-level and function-level authorization failures in API-heavy applications, where “correct” depends entirely on the relationship between the caller and the resource.
Authentication is a category where the unauthenticated view is arguably the more useful one. Lockout thresholds, account enumeration, predictable reset tokens, and session behavior at login are all testable from outside, and they’re the controls an attacker probes first. What automation misses is multi-step abuse. Chaining a password reset weakness with an enumeration flaw and a race condition takes an operator who can hold three ideas at once.
Error handling landed on the list as A10 Mishandling of Exceptional Conditions, and it’s a meaningful addition. Scanners send malformed input and read what comes back, so stack traces, database errors, and fail-open responses show up readily. The deeper version of this category, where an application enters an inconsistent state after a partial failure, needs a person to deliberately try to break in.
What a web app vulnerability scan can’t see
TL;DR: Insecure design, integrity failures, logging gaps, and chained attack paths are largely invisible to automation, and they include some of the most damaging real-world findings.
Insecure Design is the clearest example. A scanner has no model of what your application is for. It doesn’t know that your refund workflow shouldn’t allow negative amounts, that your invitation system shouldn’t let a user escalate their own permissions, or that your trial signup shouldn’t be repeatable with the same payment method. These aren’t coding mistakes, they’re missing controls in the design, and finding them requires understanding intent.
Software or Data Integrity Failures mostly live outside the running application. A scan can flag a missing subresource integrity attribute on a third-party script. It can’t tell you whether your CI pipeline verifies signatures, whether your update mechanism can be tampered with, or whether an artifact was modified between build and deploy.
Security Logging and Alerting Failures is where scanning is most obviously blind. Nothing in an HTTP response tells you whether anyone noticed the request. That said, running a scan does produce one genuinely useful finding: a scan generates a volume of unusual traffic against your application. If your monitoring never flagged it, and nobody on your team reached out to ask what was happening, you’ve learned something concrete about your detection coverage.
The largest blind spot isn’t any single category, it’s the connection between them. Scanners report findings as a flat list, but attackers don’t work that way. A medium-severity information disclosure plus a weak session control plus an over-permissive API role isn’t three medium findings. It’s one attack path to your data, and no scanner is going to connect those dots for you.
How to run a web application vulnerability scan, step by step
TL;DR: Most disappointing scan results trace back to setup rather than tooling. Scope, environment, and coverage choices determine most of what you’ll find.
- Define the scope. List the domains, subdomains, and API endpoints in play. Be explicit about what’s off-limits, especially any third-party service that shares infrastructure with you. If you don’t own it, don’t scan it.
- Decide where you’re scanning. Production gives you accurate results. Staging gives you safety. If staging genuinely mirrors production, including configuration and data volume, use staging. In practice it usually doesn’t, and the differences tend to be exactly where the misconfigurations are.
- Choose blackbox or credentialed, and know what you’re choosing. A blackbox scan needs nothing but a URL and shows you the attacker’s opening view. A credentialed scan needs test accounts and setup time, and shows you what’s reachable behind the login. Blackbox is a good starting point, as long as you note what you haven’t covered yet.
- If you’re running credentialed, prepare one account per role. At minimum a standard user and an administrator. Use dedicated test accounts you’re comfortable seeing modified. Confirm the scanner can complete your login flow, hold the session, and avoid triggering logout. If you use MFA, arrange a bypass or an API token for the test account. This is the most common failure point in credentialed scanning.
- Provide an API specification if you have one. An OpenAPI or Swagger file expands coverage considerably, because crawlers routinely miss endpoints that no UI element links to. Undocumented endpoints are a large share of modern attack surface.
- Run the scan and watch the first few minutes. Confirm the crawler is reaching the depth you expect. On a credentialed run, confirm the session is holding. A scan that dropped its session will finish and report almost nothing.
- Read the results with a triage mindset. Severity ratings are a starting point, not a concrete plan. The next section covers what to do with them.
What to do with the scan results
TL;DR: A raw scan report is a list, not a plan. Validate what’s real, sort by exposure and reachability rather than severity alone, and treat coverage gaps as findings in their own right.
Start by validating. Dynamic scanners produce false positives, especially around injection and access control, where an unusual response can look like a successful attack. Confirm the highest-severity findings manually before anyone opens a ticket. Nothing burns engineering goodwill faster than a sprint spent chasing a false positive.
Then re-sort. A critical finding on an internal admin tool behind a VPN is usually less urgent than a high finding on an unauthenticated endpoint that anyone can reach.
Ask the following questions about each finding:
- Can an attacker reach it?
- What does exploiting it actually get them?
- Is this vulnerability actively being exploited in the wild?
- What’s the business or financial impact?
- Does it put me out of compliance?
- Does it connect to anything else on the list?
That last question is the one that changes priorities the most. To learn more about vulnerability prioritization and why basic scoring fails, check out our blog written by SafeHill’s VP of Product.
Group by root cause where you can. Forty instances of a missing security header is one configuration change, not forty tickets. Twelve reflected XSS findings across different pages usually point to one shared output encoding gap. Fixing the pattern is faster.
Finally, write down what the scan didn’t cover. Anything behind the login on a blackbox run, any part of the application the crawler couldn’t reach, any workflow that needs a real transaction to exercise. That list is your untested surface, and it deserves to be visible rather than assuming it’s secure.
Where scanning stops and testing starts
TL;DR: Scanning tells you what exists. Testing tells you what an attacker could do with it. You need the first continuously and the second frequently.
The natural sequence is blackbox scan first. It’s fast, it needs nothing from your team, and it establishes a baseline from the same position an attacker occupies. Fix what it finds, particularly the misconfigurations, since those are cheap to remediate and they’re now the second most prevalent category on the OWASP list.
Then go deeper. Credentialed testing opens up the surface behind your login, and a penetration test adds what automation structurally can’t reach: business logic, chained attack paths, authorization decisions that depend on context, multi-step authentication abuse. Anything that requires an operator to reason about what your application is trying to do and then find the gap between intent and implementation.
Frequency matters more than most teams expect. A scan represents your application at one moment. If you deploy weekly and scan annually, you’re looking at a snapshot of code that shipped fifty-one releases ago. That’s the underlying case for continuous scanning with frequent deep testing, rather than a single annual exercise that satisfies an audit requirement
Start with a free scan by SecureIQ Lite
You can’t prioritize an application you haven’t looked at. A scan is the cheapest way to replace assumptions about your web application’s security with a concrete list of findings.
SafeHill’s SecureIQ Lite includes a free blackbox web application vulnerability scan. Give it a URL and it tests your application the way an attacker on the outside would, then it returns a report mapped to the categories above. No credentials to hand over, no configuration, no sales call required to get results.
When you’re ready to see what’s behind the login, SecureIQ Lite also offers 72-hour web application penetration testing, which moves to authenticated testing and adds a human operator for the business logic and access control work automation can’t do. For teams shipping often enough to need continuous coverage, DynamIQ handles ongoing web application and API testing.
Start with the free scan, fix what it finds, then decide what deserves a closer look.
Click here to sign up for your free web application vulnerability scan today.
See your app the way an attacker sees it first.
What is a web application vulnerability scan?
A web application vulnerability scan is an automated test that crawls a running application and probes it for known weakness patterns. It works from the outside in, requesting pages, submitting forms, and calling API endpoints to see how the application responds. It doesn’t need access to your source code, only a URL.
What does a web application vulnerability scan detect?
Scans reliably detect security misconfigurations, transport-layer cryptographic weaknesses, and injection flaws such as SQL injection and cross-site scripting. They partially detect access control gaps, authentication weaknesses, and error handling problems. Design flaws, integrity failures in the build pipeline, and logging gaps stay largely outside what automation can see.
What is the difference between a vulnerability scan and a penetration test?
A scan runs known checks at speed and reports what it matched. A penetration test puts a human operator in front of your application to reason about business logic, chain findings together, and confirm real exploitability. Scanning is broad and shallow by design. Testing is narrow and deep. Neither one covers the other.
What is the difference between a blackbox scan and a credentialed scan?
A blackbox scan runs with no credentials and shows you what an external attacker sees before they have any access. A credentialed scan logs in and tests the surface behind your login, including dashboards, settings, and internal APIs. Blackbox needs nothing but a URL. Credentialed needs test accounts and setup time.
Can a vulnerability scan find all OWASP Top 10 risks?
No. Coverage varies sharply by category. Security Misconfiguration and Injection are well covered by automation. Insecure Design and Security Logging and Alerting Failures are almost entirely invisible to a scan, because they depend on understanding what an application is supposed to do and whether anyone noticed an attack.
Is it safe to run a vulnerability scan on a production application?
Generally yes, though it depends on the scan and the application. Scanners submit forms and send unusual input, which can create test records or trigger notifications. Production gives the most accurate results because staging rarely matches it exactly. If you scan production, tell your team first so the traffic isn’t mistaken for an attack.
How often should you scan a web application for vulnerabilities?
A scan represents your application at one moment. If you deploy weekly and scan annually, you’re reviewing code that shipped fifty-one releases ago. Most teams shipping regularly need continuous or at least monthly scanning, with a deeper penetration test on a periodic schedule to cover what automation can’t reach.
Does a vulnerability scan satisfy SOC 2 or PCI DSS requirements?
Partly. PCI DSS requires quarterly external scanning by an Approved Scanning Vendor plus annual penetration testing, so a general-purpose scan doesn’t satisfy the ASV requirement on its own. SOC 2 doesn’t mandate a specific cadence, but auditors expect documented vulnerability management with evidence of remediation.