Sitadel scans a web application for fingerprints, injection flaws and exposed files

It is WAScan, updated and restructured

Sitadel is described as basically an update for WAScan making it compatible for Python 3.11 or newer, and the point of the fork is stated in the same sentence. It allows more flexibility for you to write new modules and implement new features.

The lineage matters for anyone who has used the original. WAScan was a well-known web application scanner with a long module list, and what had gone stale about it was the Python it ran on and how the modules were structured. Sitadel keeps the shape of the tool and changes the foundations.

The requirement warning is explicit about the consequence. This project supports Python 3.11 or newer, older end-of-life versions are no longer supported, and there will be no backport to 2.7.

The listed improvements over the original are the modules that have been added or reworked: frontend framework detection, HTML form discovery with POST and body parameter injection, Content Delivery Network detection, the ability to define a risk level to allow for scans, a plugin system, and a Docker image available to build and run.

The release tags are named rather than numbered, which is an unusual and pleasant choice. v2.0.0 is BlockHouse and v1.5.1 is Fort, both in 2026, with the last push on 2026-10-15.

The project is Python, GPL-3.0 licensed, authored by Shenril, and classified in the package metadata as Development Status 4 - Beta with the intended audience of developers, information technology and system administrators.

The risk level is the control that makes it safe to point at a live site

The scanner takes a risk flag from zero to two, and the description of it is the sentence that should decide whether you use this tool.

The risk argument decides the risk level you want Sitadel to run, and the parenthetical is the important part: some attacks will not be executed.

That single control is what separates this from a script you run blind. A scanner that issues SQL injection payloads, brute-force requests for admin consoles and backup files, and path traversal probes against a live application can change state on that application even without a human intending anything destructive. Some of those probes are a read, some are a write, and some are a nuisance that logs an administrator out or fills a log file.

So the risk level is how you say which of those you are willing to have happen. At the lowest setting you get the fingerprinting and the passive checks. As you go up, more of the attack modules run.

The same concern shows up in the project's own tooling. The Makefile has a test target that runs pytest with a marker filter excluding the dangerous tests, and a separate full_test target that runs everything with output shown. The distinction between the two is that one is safe to run on every commit and the other is not.

That is a good sign about how the maintainer thinks about it. A tool that ships a marker for its own dangerous tests is a tool whose author has thought about which parts cause damage, and the risk flag on the command line is the user-facing expression of the same idea.

Fingerprinting is half the tool

The fingerprint module list covers nine areas, and it is the half of the scanner that tells you what you are dealing with before anything is thrown at it.

There is cdn, which tries to guess if the target uses a Content Delivery Network, with fastly, akamai and cloudflare named. There is cms, for Content Management Systems such as drupal, wordpress and magento. There is framework for backend frameworks like cakephp, rails and symfony, and frontend for frontend frameworks like angularjs, jquery and vuejs.

Then there is header, which inspects the headers exchanged with the target, and that is where the security headers audit lives, along with cookie security. There is lang for the server language, server for the server technology such as nginx or apache, system for the operating system, and waf to guess whether a Web Application Firewall such as barracuda, bigip or paloalto is in front.

The header and cookie checks are the ones that matter most in practice, because they are passive. You find out that your cookies lack the secure flag, that your security headers are missing, that the server leaks its version, and that a CDN is in front of your application. None of that sends a payload.

The value of fingerprinting is also that it makes the attack phase smarter. A site running WordPress deserves a different set of probes than one running Rails, and knowing the stack before you start is what lets you narrow the attack modules rather than firing everything.

On the command line, the fingerprint modules are selected by name, with the accepted set listed as cdn, cms, framework, frontend, header, lang, server, system and waf.

The attack modules are grouped into four families

The attack side is split into four module families, selected with the attack flag: bruteforce, injection, vulns and other.

The bruteforce family is about discovering paths rather than credentials. It tries to bruteforce the location of multiple files, with the specific targets being admin interfaces, common backdoors, common backup directories, common backup files, common directories, common files and log files. In other words it is looking for things that should not be reachable, which is a class of finding that does not need a payload at all.

The injection family is the largest and the most intrusive. It covers HTML injection, SQL injection, LDAP injection, XPath injection, cross site scripting, remote file inclusion, PHP code injection, XML external entity, server-side template injection, path traversal and local file inclusion.

The vulns family checks for specific known issues, and the names are explicit about what they are: ShellShock, the anonymous cipher vulnerability from 2007, the CRIME attack against SPDY from 2012, and Struts-Shock.

The other family is the miscellaneous bucket and it is a long list: HTTP allow methods, HTML object, multiple index, robots paths, WebDav, cross site tracing, phpinfo, directory listing, WebSocket discovery and cross-site WebSocket hijacking, CORS misconfiguration, open redirect, server-side request forgery, exposed sensitive files and secret leakage in responses.

Several of those are worth pulling out because they are checks people forget to run. Cross-site WebSocket hijacking is a real finding on applications that authenticate with cookies and expose a WebSocket endpoint. CORS misconfiguration is a common finding in a self-hosted API. Secret leakage in responses means an API is returning a token in a body it should not.

And the combination attack module extends the scanning to HTML forms, discovering them and injecting into POST and body parameters, which is how the tool reaches the parts of an application that are only reachable through a form.

Running it, and the options that matter in practice

The usage line shows a small set of options and one positional argument, and most of them exist for practical reasons.

sitadel [-h] [-r {0,1,2}] [-ua USER_AGENT] [--random-agent] [--redirect]
        [--no-redirect] [-t TIMEOUT] [-c COOKIE] [-p PROXY]
        [-f FINGERPRINT [MODULE ...]] [-a ATTACK [MODULE ...]]
        [--config CONFIG] [-v] [--version]
           TARGET_URL

The options that will change your results most are the risk level, the module selection and the config file. The fingerprint flag takes a list of modules and the attack flag takes a list of module families, so you can scan for headers and cookies only, with no attack modules at all, which is the passive pass. The config flag points at a config file, with the default one in config/config.yml.

The request-shaping options are the user agent, the random agent flag that uses a different User-Agent for each scan request, the redirect and no-redirect flags for whether to follow a 302, the timeout, the cookie to send with the attack requests, and the proxy to perform the HTTP requests through.

The random agent option deserves a mention because it is a common scanner feature and it is worth understanding what it is for. A server or a WAF that is rate-limiting or blocking by user agent will produce very different results depending on whether you send the same agent every time, so randomising it reduces the chance that a single block makes the whole scan look clean.

The cookie option is there for authenticated testing, and the proxy option is there for routing through your own infrastructure rather than scanning directly from your workstation.

Verbosity is adjustable with -v, and the documentation gives the example of -v, -vv and -vvv, which is what you want when a module is not reporting something you expect and you need to see what it actually did.

The packaging is a normal Python project with a text UI option

The project metadata shows a modern setuptools build with a dynamic version taken from the sitadel package attribute, and a console script named sitadel mapped to sitadel.cli:main.

The dependencies are the interesting part, because they say what the scanner does. requests and urllib3 for synchronous HTTP, aiohttp for asynchronous requests, which matters for a scanner that has to issue many requests, selectolax for HTML parsing, mmh3 for the MurmurHash3 function that many fingerprinting checks rely on, jsonschema for validating responses, PyJWT for inspecting tokens, cryptography for handling certificates and keys, websocket-client for the WebSocket checks, pyyaml for the configuration files and colorama for terminal output.

There are two optional extras. The tests extra pulls pytest and flake8, and the tui extra pulls textual at 0.60 or newer, which is the library for terminal user interfaces.

The textual extra is the newest idea in the project and it is a good one for a tool like this. A scanner that has to report which of nine fingerprint modules ran, which of four attack families ran, and what each found is a candidate for a proper terminal interface rather than a wall of log lines, and textual is the standard choice for that in Python now.

The Dockerfile is minimal and does the right thing:

FROM python:3.13-slim

WORKDIR /usr/src/app
COPY . /usr/src/app

RUN pip install --no-cache-dir .

ENTRYPOINT ["sitadel"]

A slim Python 3.13 base, the source copied in, a single pip install with no cache, and the console script as the entrypoint. That means the image runs as `sitadel <target>` with no wrapper.

The repository also carries a Makefile with the test, full_test, clean and lint targets, where lint runs flake8 with the long-line check ignored and a separate criticalint target that selects only the syntax and undefined-name error codes, which is the check you want to fail a build on.

Editorial conclusion

Adopt Sitadel if you own the web application or have written authorisation to test it and you want a single tool that fingerprints the stack and probes it for common web flaws, because it covers both halves in one run. Skip it if you need a payload-based exploitation framework, since this is a scanner that reports rather than a toolkit that pivots, and if your environment is not Linux on Python 3.11 or newer. Verify first which risk level you run at, since the tool will issue live injection and brute-force requests against whatever you point it at, that you have the module set narrowed with the fingerprint and attack flags rather than taking the defaults, and that you run it against a staging copy rather than production if the site has any side effects.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. shenril/Sitadel on GitHub