Nikto Web Scanner Tutorial: A Practical Guide for 2026

Nikto is one of the most well-known open-source web server scanners in the penetration tester’s toolkit. Originally written in Perl by Chris Sullo, it has been around for over two decades — but it remains genuinely useful for quickly identifying misconfigurations, outdated software, and known vulnerabilities on web servers. This guide covers everything from basic usage through to dealing with modern obstacles like Cloudflare’s TLS fingerprinting.

What is Nikto?

Nikto is a command-line web server scanner that checks targets against a database of over 7,000 potentially dangerous files, outdated server versions, and common misconfigurations. It supports HTTP and HTTPS, can scan multiple ports, and produces output in a variety of formats. It ships by default with Kali Linux and is straightforward to install on any Debian-based system.

It’s worth being clear about what Nikto is and isn’t. It’s a noisy scanner — it makes no attempt to be stealthy, and any competent IDS or WAF will detect it immediately. That makes it ideal for authorised assessments of your own infrastructure, CTF boxes, and lab environments, but unsuitable where stealth matters. Always ensure you have written permission before scanning any system you don’t own.

Installing Nikto

On Kali Linux, Nikto is already installed. On other Debian-based systems:

sudo apt update && sudo apt install nikto

You can also clone the latest version directly from GitHub:

git clone https://github.com/sullo/nikto
cd nikto/program
perl nikto.pl -h example.com

Basic Usage

The simplest scan just requires a host:

nikto -h example.com

By default Nikto doesn’t give much feedback while running. Adding verbose output helps you see what’s happening in real time:

nikto -Display V -h example.com

To scan a specific port (useful when a web server isn’t on the default port):

nikto -h example.com -p 8443

To force HTTPS:

nikto -h https://example.com

Tuning Scans

One of Nikto’s most useful features is the -Tuning flag, which lets you restrict the scan to specific test categories rather than running everything. This speeds things up and reduces noise when you’re looking for something particular.

• 0 – File Upload
• 1 – Interesting File / Seen in logs
• 2 – Misconfiguration / Default File
• 3 – Information Disclosure
• 4 – Injection (XSS/Script/HTML)
• 5 – Remote File Retrieval – Inside Web Root
• 6 – Denial of Service
• 7 – Remote File Retrieval – Server Wide
• 8 – Command Execution / Remote Shell
• 9 – SQL Injection
• a – Authentication Bypass
• b – Software Identification
• c – Remote Source Inclusion
• x – Reverse Tuning (exclude specified tests)

For example, to run only SQL injection checks:

nikto -Tuning 9 -h example.com

Or to run everything except Denial of Service tests:

nikto -Tuning x6 -h example.com

Saving Results

Nikto supports output to file in several formats using the -o and -Format flags. Supported formats include csv, htm, txt, xml, and json. For example, to run an information disclosure scan and save the results as HTML with verbose terminal output:

nikto -Display V -o results.html -Format htm -Tuning 3 -h example.com

The XML and JSON output formats are particularly handy if you want to feed results into another tool or write a script to parse them.

Using a Proxy with Nikto

You can route Nikto traffic through a proxy using the -useproxy flag. This is useful for capturing requests in Burp Suite or for routing through a SOCKS proxy:

nikto -h example.com -useproxy http://127.0.0.1:8080

Nikto and Cloudflare: The TLS Fingerprinting Problem

If your target is sitting behind Cloudflare, you’ll quickly run into a frustrating problem: Nikto’s requests get blocked before they ever reach the origin server. This isn’t just about IP reputation or rate limiting — the more fundamental issue is TLS fingerprinting.

Cloudflare uses a technique that analyses the TLS ClientHello message sent during the SSL/TLS handshake. This fingerprint — sometimes referred to as a JA3 hash — is derived from details like the TLS version, cipher suites, extensions, and elliptic curves advertised by the client. Because Nikto is written in Perl and uses its own TLS implementation, it produces a distinctive fingerprint that Cloudflare (and other WAFs) recognise as scanner traffic and block outright, often returning a 403 or simply closing the connection.

The practical consequence is that running nikto -h https://target-behind-cloudflare.com will either time out or return nothing useful. The scan never sees the real application.

Option 1: Route through mitmproxy

mitmproxy is a powerful interactive HTTPS proxy. Because it handles the TLS handshake itself — using its own modern TLS stack — it presents a far more browser-like fingerprint to upstream servers. By routing Nikto through mitmproxy, Cloudflare sees mitmproxy’s TLS fingerprint rather than Nikto’s.

First, start mitmproxy in regular proxy mode:

mitmproxy --listen-port 8080

Then point Nikto at it:

nikto -h https://target.com -useproxy http://127.0.0.1:8080

You may also need to tell Nikto to ignore SSL certificate errors from the proxy:

nikto -h https://target.com -useproxy http://127.0.0.1:8080 -nossl

In mitmproxy’s interface you can watch all the requests flowing through and see whether responses are coming back from the actual origin or being intercepted by Cloudflare.

Option 2: Route through Burp Suite

Burp Suite Community or Professional can be used in exactly the same way. Burp’s embedded browser uses a Chromium-based TLS stack, and Burp itself presents a much more convincing fingerprint than Nikto does natively. Start Burp, ensure the proxy listener is running on 127.0.0.1:8080, then run:

nikto -h https://target.com -useproxy http://127.0.0.1:8080

You’ll be able to see all Nikto’s requests appearing in Burp’s HTTP history tab, which is handy for understanding exactly what’s being sent and troubleshooting any blocked requests.

It’s worth noting that even with improved TLS fingerprinting, Cloudflare’s bot detection has multiple layers — behavioural analysis, rate limiting, and JavaScript challenges among them. For a thorough assessment of a Cloudflare-protected target you’ll likely need to combine Nikto with manual testing in Burp Suite, and ideally get the origin IP directly so you can bypass Cloudflare entirely and hit the server head-on.

Nikto’s Limitations

Nikto is a great first step in a web assessment, but it has real limitations worth keeping in mind. It produces a significant number of false positives, particularly around headers and version detection. It doesn’t do any authenticated scanning by default (though you can pass credentials with -id user:pass). And as noted above, it’s trivially detected by any WAF or IDS.

For deeper application-layer testing, pair Nikto with tools like Burp Suite for manual testing, Wapiti for automated web app scanning, or run it against a lab environment like those on Hack The Box or TryHackMe where you can validate findings without worrying about authorisation.

You might also find my Metasploit tutorial useful once Nikto has given you a list of potential vulnerabilities to investigate further.