A site scanner is a tool that crawls a running website and actively probes its pages, forms, and endpoints for security weaknesses such as injection flaws, misconfigured headers, and outdated components. Unlike a code scanner that reads source files, a site scanner tests the application from the outside the way an attacker would — which is why this technique is called dynamic application security testing, or DAST. If you have searched for how to "scanner un site web," this is the category of tool you are looking for.
Let me walk through what actually happens during a scan, what a site scanner can and cannot find, and how to choose and run one responsibly.
What a site scanner actually does
A typical web scan runs in two broad phases.
Crawling. The scanner starts from a URL and follows links, submits forms, and maps out every reachable page and parameter. Modern scanners execute JavaScript so they can discover routes in single-page apps, not just static HTML. The output is an inventory of endpoints and inputs.
Auditing. For each input it found, the scanner sends crafted requests and analyzes the responses. It's looking for tell-tale behavior: an error message that leaks a SQL fragment, a reflected value that suggests cross-site scripting, a header that's missing, a cookie without the Secure flag.
The result is a report of findings ranked by severity, ideally with the request that triggered each one so you can reproduce it.
What it can find — and what it can't
A good site scanner reliably catches:
- Reflected and some stored cross-site scripting (XSS).
- SQL injection and other injection classes that produce observable behavior.
- Missing or weak security headers (
Content-Security-Policy,Strict-Transport-Security,X-Content-Type-Options). - Insecure cookie flags and mixed-content issues.
- Known-vulnerable JavaScript libraries served to the browser.
- TLS/certificate misconfigurations.
What it struggles with:
- Business logic flaws — a scanner doesn't know that "users shouldn't be able to approve their own expense report."
- Authenticated, multi-step workflows unless you configure credentials and record the login sequence.
- Broken access control between roles, which usually needs human testing.
DAST is a complement to, not a replacement for, static analysis and dependency scanning. Each sees a different slice of the risk.
Tools worth knowing
For scanning a site, the common options:
- OWASP ZAP — free, open source, scriptable, with both a spider and active scanner. A great starting point.
- Nikto — fast checks for known dangerous files and server misconfigurations.
- Nuclei — template-driven scanning that's excellent for checking many hosts against known issues.
- Commercial DAST — hosted platforms that add authenticated scanning, scheduling, and reporting.
A quick ZAP baseline scan via Docker looks like:
docker run -t ghcr.io/zaproxy/zaproxy zap-baseline.py \
-t https://example.com -r report.html
That runs a passive-leaning baseline that won't hammer the target, which makes it safe to point at staging. For a full active scan you'd use zap-full-scan.py — and you'd only do that against systems you own.
The rule you cannot skip: authorization
Only scan sites you own or have explicit written permission to test. An active site scanner sends malicious-looking payloads and can trip intrusion detection, corrupt data via form submissions, or degrade performance. Running one against a third party without authorization is likely illegal in most jurisdictions. When you do scan "scanner site" targets you control, prefer staging environments and coordinate with whoever operates the system.
Running a scan that's useful, not noisy
A scan is only valuable if the findings are actionable. Some practices that help:
- Authenticate. Give the scanner valid session credentials so it can reach the pages behind login, which is where the real logic lives.
- Scope it. Exclude logout links, destructive admin actions, and third-party domains so the crawler doesn't wander or nuke your test data.
- Tune for false positives. DAST is prone to them; triage and mark false positives so each subsequent scan gets cleaner.
- Integrate into CI. A baseline scan on every deploy to staging catches regressions early.
If you want managed dynamic scanning wired into your delivery pipeline with authenticated crawling and finding management, Safeguard's DAST product is built for exactly that workflow. For the code side of the picture, our code vulnerability scanning tools guide covers static and dependency analysis.
Combining scanners for real coverage
The strongest posture layers three lenses: a site scanner (DAST) testing the running app, static analysis (SAST) reading the source, and software composition analysis (SCA) auditing dependencies. A missing security header shows up in DAST; a hardcoded secret shows up in SAST; a vulnerable library shows up in SCA. Rely on any one alone and you have blind spots the others would have caught.
FAQ
Is a site scanner the same as a vulnerability scanner?
A site scanner (web application scanner) is a specific kind of vulnerability scanner focused on web apps and their runtime behavior. Broader "vulnerability scanners" like network scanners also probe open ports and OS-level issues. For web app security specifically, you want a DAST-style site scanner.
Can a site scanner break my website?
An active scan can, because it submits forms and sends attack-like payloads that may create junk data or trigger errors. Run active scans against staging, scope out destructive actions, and start with a passive or baseline scan against production if you must scan it at all.
Do I need to log the scanner in to my site?
For meaningful results, yes. Most of an application's functionality and its highest-risk logic sit behind authentication. Configure the scanner with test credentials and, for complex logins, record the authentication sequence so it can maintain a session while crawling.
How often should I scan a website?
Run a baseline scan on every deploy to staging, and a fuller authenticated scan on a regular cadence — weekly or per release for active applications. Any significant change to inputs, authentication, or third-party scripts is a good trigger for an extra scan.