If you want to scan site web targets for real vulnerabilities rather than a surface-level port check, the process has a specific order: define the scope, authenticate the scanner as a real user, let it crawl and interact with the application, then triage what comes back against what's actually reachable in production. Skipping the authentication step is the most common mistake — it turns a thorough scan into a shallow one that only sees the logged-out pages.
What do you need before you start a scan?
Before you scan websites, you need a defined scope, a non-production target if at all possible, and explicit authorization — scanning a site you don't own or manage without permission can violate terms of service and, in some jurisdictions, computer-abuse law. Define scope as a list of hostnames and paths that are in bounds, and exclude anything you don't want probed (payment processors, third-party auth providers, anything rate-limited by a partner). Run the scan against a staging environment that mirrors production data shapes and routes, since scanning production directly risks triggering real side effects — a DAST tool crawling a live site will click every button it finds, including "delete account" if nothing stops it.
How do you configure authenticated scanning?
You configure authenticated scanning by giving the scanner valid session credentials or a login sequence it can replay, because most of an application's actual attack surface sits behind a login wall. An unauthenticated scan of a typical SaaS product might touch the marketing site and login page and little else; an authenticated scan reaches the dashboard, the API endpoints the frontend calls, and every workflow a logged-in user can trigger. Most scanners support this through a recorded login macro, a session cookie you paste in directly, or OAuth/API token injection into request headers. Use a dedicated test account with realistic but limited permissions — not an admin superuser — so the scan results reflect what an actual attacker with a compromised low-privilege account could reach, and repeat the exercise with an elevated-role account if privilege escalation is part of your threat model.
How does the crawl and probe phase actually work?
The crawl phase walks every reachable link, form, and API call the scanner can discover from the entry points you gave it, building a map of the application before it starts sending attack payloads. Modern single-page applications complicate this — a crawler that only follows <a> tags misses routes rendered by client-side JavaScript, so a capable scanner needs to execute JS and interact with the DOM the way a headless browser would. Once the map is built, the probe phase sends crafted inputs — SQL injection payloads, XSS strings, path traversal attempts, malformed JSON bodies — at every parameter it found, and watches responses for signs the payload had an effect: a database error message, a reflected unescaped script tag, a status code that shouldn't be possible for that input. This is the core of dynamic application security testing, and it's most useful run against a fully deployed instance rather than source code, because it validates the actual runtime behavior instead of a theoretical code path.
How do you use a free website scanner without missing real risk?
Free tiers of website vulnerability checker tools are genuinely useful for a first pass, but they typically cap scan depth, request volume, or authenticated-scan support, so budget for the gap. If you're searching in French for how to scanner un site web (scan a website) or looking for a scan site web en ligne (an online website scan), the same rule applies: a free online scanner is fine for a quick baseline, but it won't replace an authenticated, full-crawl scan. A free scan will usually surface missing security headers, expired TLS certificates, and obvious injection points on unauthenticated pages — useful signal, but a small fraction of what an authenticated, full-crawl scan against your actual routes will find. Use the free tier to build a baseline and catch the cheap wins immediately, then move to a paid or open-source tool with authenticated crawling and API-aware scanning before you rely on results for a compliance attestation or a customer security questionnaire.
How do you triage what a scan finds?
You triage scan findings by checking whether the flagged endpoint is actually reachable by an unauthenticated or low-privileged attacker in production, because DAST tools report on what they observed, not on business impact. A "medium" finding on an internal admin tool that's only accessible from a VPN carries far less real risk than a "medium" finding on a public signup form, even if the raw scanner severity score is identical. Cross-reference findings against your SCA and code-scanning results too — a DAST finding of reflected input on a parameter, paired with a known-vulnerable templating library flagged by SCA, is a much stronger signal than either alone. Fix confirmed issues in order of exploitability and exposure, not raw CVSS score, and re-scan after each fix to confirm it actually closed the gap rather than just moved it.
FAQ
What's the difference between scanning a website and scanning source code?
Website scanning (DAST) tests a running application from the outside, sending real requests and observing real responses — it finds issues that only appear at runtime, like misconfigured headers or broken auth checks. Source code scanning (SAST) reads the code itself and finds patterns like unsafe string concatenation before the app ever runs. The two catch different things and work best together.
How often should you scan a production website?
At minimum on every release, and ideally continuously — a scheduled scan on a weekly or nightly cadence catches issues introduced between releases (like a newly disclosed CVE in a dependency the site loads) that a release-gated scan alone would miss.
Can a website scanner test API endpoints, not just pages?
Yes, if it's configured with an OpenAPI/Swagger spec or a captured traffic log to seed its crawl — API-aware scanners send structured requests against documented endpoints rather than relying purely on discovered HTML links.
Will scanning a website vulnerability checker slow the site down for real users?
It can, if run against production with aggressive concurrency settings. Rate-limit the scan, run it during low-traffic windows, or target a staging environment that mirrors production to avoid impacting real users.