Reports distinguish completed checks, skipped checks and uncertainty. No findings does not mean there are no vulnerabilities.
What we check. What we need from you.
Coverage depends on the selected profile, approved scenarios and available data. A completed scan is not a guarantee that all vulnerabilities were found.
What runs automatically
After address verification and your consent, scans check HTTPS/TLS, headers, CORS, exposed configuration, debug pages and a reviewed Nuclei pack: 40 full-profile rules and 9 short-profile rules. Declare each address’s stack to skip unrelated checks. An unknown-path control excludes SPA fallbacks. Bounded HTML discovery reads up to 3 pages in short scans and 10 in full scans; forms are inventoried, never automatically submitted. Full scans also execute approved GET/HEAD operations with concrete paths. Enable a schedule for recurring scans; dependency monitoring needs an inventory and an enabled service.
What the owner provides
Provide a website/API URL, file or DNS ownership proof, and scan consent. API checks need OpenAPI or concrete operations. Access checks need dedicated test accounts, roles, known fixture objects, unique markers and expected allow/deny outcomes. Dependencies need exact versions from npm package-lock, CycloneDX SBOM or manual input. Schema import alone neither approves requests nor proves business-logic coverage.
Which checks require staging
SQLi, XSS, active CVE checks, Mass Assignment and rate-limit diagnostics require a staging environment on Pro/Business and separate consent per scenario. Mutation checks need a test fixture and verifiable restoration. External checks and approved read scenarios may run in production. SQLi/XSS support query parameters, POST forms and selected nested JSON fields. XSS confirmation replays HTML in Chromium with response CSP and no subresources. The service does not automatically try every CVE.
What partial coverage means
Some checks ran, but others lack evidence: an expired session, missing scenario, WAF, unavailable target or exhausted budget. Skipped means not executed; inconclusive means an attempt gave no reliable conclusion; not applicable means the check does not fit the response or technology. Existing findings remain valid. No findings with incomplete coverage is not proof of security. Address the stated cause and rerun; review each scenario, not just the overall status.
Supported authentication
Bearer tokens, API keys in a header, cookies and JSON login with token extraction and configured refresh. Provide a session-check path and use Validate access. JWT checks support configured issuer/audience and trusted JWKS. Secrets are encrypted and never returned to the interface. GitHub OAuth signs you into Scantelio separately. Browser login with CAPTCHA/MFA and automatic browser crawling are not supported.
Available notifications
The inbox supports reading and archiving messages. External notifications use private Telegram bot messages after linking, subject to your plan. Preferences cover important findings, scan summaries, vulnerable dependencies, service updates and marketing. Dependency alerts apply only to your project's packages and affected versions; unknown versions do not produce confirmed Telegram alerts. No email notifications. Administrators can message selected customers or the eligible audience.
Ownership verification and authorization to test
Scantelio is intended for your own websites and APIs or systems you have explicit permission to test. Before scanning each target, the service verifies control through a DNS record or verification file and then requires separate consent to test. The server blocks scan creation without both verification and consent.
SQLi, XSS and active CVE scenarios additionally require staging and separate approval for each scenario. Runs have request, time and scope limits. Matching an uploaded dependency inventory against known vulnerability databases is a separate operation, not a website scan.
A DNS record or file proves technical control of a target; it does not replace legal authorization from all relevant rights holders. Customers are responsible for obtaining that authorization. Unauthorized testing of third-party systems is prohibited.
External configuration
EXT-01: TLS trust, hostname and certificate expiry; HTTP-to-HTTPS redirect within verified scope.
EXT-02: HSTS, HTML CSP, frame protection, nosniff, Referrer-Policy and session cookie attributes.
EXT-03: external Origin. Cookie-credential CORS is suspected without proof of browser exploitation; a public wildcard is not a vulnerability by itself.
EXT-04: structural checks for .env and .git/HEAD, without retaining secrets.
EXT-05: stack traces, debug pages and directory listings.
EXT-06: optional SPF / DKIM / DMARC TXT checks. No DKIM selector means unknown; actual outgoing-mail signatures are not verified.
DAST · Nuclei
Nuclei 3.11.1 uses the reviewed Scantelio HTTP pack, with GET requests restricted to verified scope. There are 9 short-profile rules and 40 full-profile rules: configuration, backups, Git/SVN, PHP, Spring, Apache, Laravel/Symfony, Go, WordPress, Drupal, Joomla, Magento, Rails, ASP.NET, npm and operational endpoints. Declared stacks skip irrelevant specialized rules; an undeclared stack uses a broad profile. An unknown-path control helps exclude SPA fallbacks. Login and WAF pages limit coverage. Pro and Business have the same detection quality within their budgets.
Public diagnostic resources are suspected findings: verify their purpose and the sensitivity of the data. This is not proof of CVE exploitation. A targeted retest runs the selected finding’s rule. An unavailable engine, redirect, truncated response or exhausted budget produces incomplete coverage. Arbitrary code, browser templates, OAST and arbitrary community templates are not executed by this pack. New templates undergo review and testing.
MinIO CVE-2023-28432 requires a staging cluster and a unique owner-provided MINIO_SCANTELIO_FIXTURE marker. Environment values are not retained. cPanel XSS also supports isolated browser confirmation.
Route and parameter discovery
Bounded discovery reads up to 3 HTML pages in a short scan and 10 in a full scan, within the verified address and shared budget. It collects links, query parameters and form field names, up to 40 input descriptions. Passwords, field values and secret parameters are not retained. Forms are not automatically submitted. For an active check, configure the chosen path and test values in a staging scenario. Dynamic JavaScript routes, hidden paths and authenticated pages are not crawled. Reports distinguish discovered inputs from checks actually executed.
Active DAST · staging only
Pro and Business use the same SQLi/XSS scenarios and six CVE modules within a full-run budget. A verified target, test data and separate consent for each scenario are required. SQLi uses two repeatable true/false AND controls and SQL error checks for a selected query, POST form or nested JSON field; no UNION, database extraction or time delays. XSS uses bounded markers for HTML contexts. Reflection in an executable context is suspected. With confirmation enabled, two independent markers are tested in Chromium by replaying the HTML with its original CSP and blocking additional network requests. Execution in that replay is confirmed; it is not a full browser user-journey test. HTTP applications may use PHP, Java, Node.js, Python, .NET, Ruby, Go or other stacks.
CVE-2025-29927 (Next.js) checks access to a private test marker. CVE-2017-9841 (PHPUnit) uses two PHP hash calculations. CVE-2022-26134 (Confluence) uses two arithmetic OGNL probes with a response header. CVE-2018-20062 (ThinkPHP) uses two hash calculations through its dispatcher. CVE-2023-29489 (cPanel) checks HTML-context reflection. Only the explicitly selected module for the component technology runs; there is no blanket CVE probing. No operating-system commands, file reads, data extraction, persistent payloads or arbitrary scripts. Confirmation for the first four requires control evidence; cPanel reflection alone remains suspected.
DOM/stored XSS, blind/time-based SQLi, multipart/file uploads, arbitrary JSON-field fuzzing and exploitation chains are unsupported. Only the selected field and approved test POST body are checked. Inapplicable responses, WAF blocks, changed baselines, errors and exhausted budgets do not mean fixed.
Authenticated API
Supported authorization includes Bearer, API key, Cookie, JSON login and refresh. AUTH-01 checks BOLA/tenant isolation using two known fixtures and unique markers. AUTH-02 covers role/field checks; Mass Assignment requires staging, separate consent and verifiable restoration. AUTH-03 covers JWT signature tampering, alg:none, exp and a configured public JWKS; independent expiry checks need a formerly valid expired token. AUTH-04 makes at most 20 requests at one request per second in an approved staging scenario. No 429 is Info/suspected, not proof of a bypass.
Dependencies
Supported inputs: npm package-lock v2/v3 and CycloneDX 1.5/1.6 with exact versions and purl for npm, PyPI, Maven, Go, crates.io, Packagist, NuGet, RubyGems, Hex and Pub. Sources include OSV version ranges, NVD context and CISA KEV. Unknown versions remain unknown. Withdrawal or changed fix information updates the match. An advisory does not prove exploitation. An SCA match does not start active exploitation; active CVE scenarios are separately configured for staging.
Each host and path prefix requires separate verification. Proof is checked again before execution; networking uses DNS validation and IP pinning with Host/SNI. Credentials are not forwarded across origins. TLS verification stays enabled, and decompressed response bodies are limited to 256 KB. All requests are bounded by the budget and worker lease.
Contact and stopping a scan
The operator configures the abuse contact through SCANNER_CONTACT before public launch. You can stop an active local scan from the workspace.