Scan Scope & Address Tiers

Nikto Platform drives a real browser and follows links, redirects, and page includes the way a browser does. To keep a scan from being turned into a tool for reaching machines you did not intend to touch, the scanner limits where a scan may go based on the address of the URL you entered — not a scope list you have to configure.

The three tiers

Every address the scanner might contact falls into one of three tiers:

Tier	What it is	Examples
Public	A normal, internet-routable address	example.com, 93.184.216.34
Private	An internal / RFC1918 network address	10.x.x.x, 172.16–31.x.x, 192.168.x.x, 100.64.x.x, IPv6 ULA
Local	Loopback and link-local, including cloud metadata	127.0.0.1, ::1, 169.254.169.254

The rule

A scan may follow links and load resources at its own tier or a more public one — never a more private one. The tier is set by the target URL you type when you start the scan.

• You scan a public site → the scan can load its public resources, but it does not follow a link or include into a private (internal) or local address. This is what stops a hostile or compromised page from steering your scanner at your internal network.
• You scan an internal site → the scan behaves like a browser on your internal network: it loads that host's internal API, CSS, and scripts (private-tier resources) and any public resources it references. It still does not follow links down to loopback or cloud metadata.
• You scan localhost / the host machine → you are explicitly at the most local tier, so the scan may load anything the target references.

In every case, you can still scan an internal or local target directly by entering its URL. What the tier rule blocks is a scan pivoting on its own, from content it fetched, to a more private address than the one you chose.

The scanner never fetches cloud metadata itself

This rule is about your scanner host, not the target. If the machine running Nikto Platform is a cloud instance, it has its own metadata service at 169.254.169.254 holding instance credentials, and a hostile page could try to make the scanner load that URL as a subresource — an image, a redirect, a favicon — and hand the response back as scan output. That is the pivot being closed.

The link-local ranges 169.254.0.0/16 (IPv4, which includes the cloud metadata endpoint 169.254.169.254) and fe80::/10 (IPv6) are refused as a followed resource on every scan, regardless of tier, unless the host is the exact target you typed. Reaching a cloud provider's metadata service through a scanned page is a classic server-side request forgery target, and a scan has no legitimate reason to load it as a subresource. There is no setting that turns this off.

The same exemption applies to a one-off operator-initiated probe — an LFIC setup probe, for example — where the host you named is the probe's target. Anything else the scan reaches on its own is refused.

Testing the target for SSRF and open proxying is unaffected. Those checks connect to the target you typed and ask it to fetch a metadata URL (the address goes in the request line and Host header, never in a connection the scanner opens). The block above applies to addresses the scanner dials, so metadata, WBEM and proxy-bypass checks run normally.

What you see

When the scanner declines to follow a resource because of this rule, it is logged, not silent: the blocked request appears in the scan's activity log named by host, with the reason. If you scan a public site and expected it to follow an include into your internal network, that block is the tier rule doing its job — scan the internal target directly instead.

Scanning the machine that runs the scanner

Entering localhost or 127.0.0.1 targets the host machine the platform runs on (see Docker Deployment). This works on Linux as well as Docker Desktop.

The platform's own services are never reachable from a scan, regardless of tier: the API listen address, the Chromium DevTools endpoint, and host.docker.internal on the API port. That includes LFIC setup probes — they use the same block. A scan of an internal host cannot be turned into a probe of the console itself.

See Scans for launch-time DNS checks and Web Crawler for how crawls follow (or refuse) links.