OpenDoor is a free, open source frameworks & platforms project written in Python and released under GPL-3.0. It has 1,008 GitHub stars, 187 forks and 4 open issues, and was last pushed 6 days ago. On this registry it ranks #70 of 75 tracked projects in Frameworks & Platforms, with 5 head-to-head comparisons available.

What is OpenDoor?

OpenDoor is an open-source, GPL-3.0 OWASP command-line reconnaissance platform, written in Python, that automates directory discovery, subdomain enumeration, fingerprinting and WAF detection for security researchers, penetration testers, bug bounty hunters, DevSecOps engineers and developers working on systems they own or are explicitly authorized to test.

What it is

OpenDoor lives in the OWASP ecosystem and ships as the opendoor package on PyPI, alongside a Homebrew formula, a Chocolatey package and a published Docker image, with documentation hosted on Read the Docs. It requires Python 3.12 or newer and is built as a CLI-first platform, combining directory discovery, subdomain enumeration, fingerprinting, WAF detection, bypass probing, response filtering, reporting, open-redirect checks, a bounded crawl and transport-based scanning workflows in a single tool.

The concrete problem it solves is the fragmentation of ad-hoc web reconnaissance. Instead of maintaining one script for directory brute-forcing, another for fingerprinting and a third for WAF detection, a tester runs one platform that performs wordlist-driven path discovery and surfaces exposed paths, login panels, directory listings, restricted resources, backup files, web shells and subdomains, along with other sensitive assets. The topic list places it among dirsearch-style directory brute-forcers, which is the class of tooling it replaces.

Key capabilities

  • Wordlist-driven directory, path and file discovery, tagged with topics such as directory-bruteforce, path-discovery, content-discovery and directory-scanner, aimed at exposed paths, login panels, directory listings, backup files and web shells.
  • Subdomain enumeration that extends the known attack surface beyond a single hostname.
  • Fingerprinting and WAF detection (fingerprinting, waf-detection), identifying the technology stack and any intervening firewall in the same run.
  • Bypass probing with response filtering, which separates meaningful hits from the noise of a brute-force sweep.
  • Open-redirect checks and a bounded crawl that limits how far a site is traversed.
  • Proxy rotation and transport-based scanning workflows (proxy-rotation, tunnel-scan) for routing requests through intermediary transports.
  • Reporting, URL bruteforcing and URL fuzzing (url-bruteforcer, url-fuzzing, web-fuzzer) from a Python 3.12+ command-line interface.

Who users are and how they work

  • Penetration testers run it during authorized engagements to map exposed directories, login panels and backup files before manual testing begins.
  • Bug bounty hunters use it to enumerate subdomains and paths across a program's in-scope assets.
  • DevSecOps engineers and developers point it at their own applications to check what is publicly reachable before release.
  • Security researchers use its transport-based scanning and response filtering, keeping runs controlled with the bounded crawl and proxy rotation.
  • With a CI matrix spanning Linux, macOS and Windows on Python 3.12, 3.13 and 3.14 plus a Docker image, it suits both workstation and container-based workflows.

Getting started

OpenDoor installs from PyPI as the opendoor package, or through the Homebrew formula, the Chocolatey package or the published Docker image. Installation, update and quickstart instructions are maintained in the documentation at opendoor.readthedocs.io.

How it compares

No paid products are listed among the facts as being replaced. The closest named relative is dirsearch, which appears in OpenDoor's own topic list: OpenDoor occupies that same directory-brute-forcing territory while extending into subdomain enumeration, fingerprinting, WAF detection and reporting. It is a GPL-3.0 project with no commercial tier described.

When to use it — and when not to

OpenDoor is intended only for systems you own or are explicitly authorized to test, and wordlist-driven scanning is inherently noisy, so it is a poor fit where traffic would disturb production services or where testing is not permitted. It is a command-line tool: the facts describe no graphical interface and no hosted option, and source installs require Python 3.12 or newer. The repository front page leads with status badges, a CI matrix and documentation links, so a prospective user should expect operational detail to come from Read the Docs rather than the README itself.

project readme (upstream, from github) — read inline

OpenDoor — OWASP Web Recon & Directory Discovery Platform

OpenDoor

OpenDoor is an open-source CLI Recon Platform for authorized web reconnaissance, directory discovery, subdomain enumeration, fingerprints, WAF detection, bypass probing, response filtering, reporting, open-redirect checks, bounded crawl and transport-based scanning workflows.

It helps security researchers, penetration testers, bug bounty hunters, DevSecOps engineers, and developers identify exposed paths, login panels, directory listings, restricted resources, backup files, web shells, subdomains, and other potentially sensitive web assets.

Use OpenDoor only on systems you own or have explicit permission to test.


✅ Project status

PyPI version Homebrew Chocolatey Version Python 3.12+ Docker Image

Coverage CodeQL Codacy Security Scan Documentation Status

🧪 CI matrix

Platform Python 3.12 Python 3.13 Python 3.14
Linux Linux 3.12 Linux 3.13 Linux 3.14
macOS macOS 3.12 macOS 3.13 macOS 3.14
Windows Windows 3.12 Windows 3.13 Windows 3.14

🚀 Quick links


✨ Features

  • directory discovery;
  • recursive directory discovery;
  • bounded same-origin crawl;
  • redirects following;
  • subdomain enumeration;
  • multi-threading scans for faster lookups;
  • single target, target file, stdin, IPv4 CIDR, and IPv4 range input modes;
  • custom wordlists, prefixes, shuffling to break scan patterns and extension filters, remote wordlists supports;
  • custom request headers, cookies forwarding, and raw HTTP request templates;
  • response filters by status, size, text, regex, and body length;
  • response sniffers for detecting directory listings, empty responses, known file exposures, active shadow-copy probes, collation, possible exposed secrets, client-exposed endpoints, errors, exposed debug stack traces, and verified open redirect vulnerabilities;
  • smart auto-calibration for soft-404, wildcard, catch-all, semantic response-diff, and DNS wildcard cases;
  • technology fingerprint detection for CMS, ecommerce platforms, frameworks, runtime stacks, infrastructure, and HSTS posture;
  • passive privacy-risk checks in --fingerprint, including possible HSTS, ETag/cache, and supercookie surfaces.
  • passive WAF detection and bypass in secure scanning mode;
  • WAF guard stop condition for ending low-value scans when initial classified responses are overwhelmingly WAF-blocked;
  • controlled header and path bypass probes for blocked 401 and 403 resources;
  • fault-tolerant scan runtime with retries, fail-streak protection, transport failure handling, resumable sessions, and runtime pause/resume controls;
  • CI/CD fail-on result bucket rules;
  • differential report comparison for previous/current JSON or SQLite reports;
  • reports in terminal, text, JSON, CSV, HTML, SARIF and SQLite formats;
  • proxy, OpenVPN, WireGuard, legacy TLS, and mTLS client-certificate transport support;
  • sequential per-target transport rotation for batch workflows;
  • configuration wizard for repeatable scan profiles;
  • built-in wordlists (upd. 2026-08)

🧭 Where does OpenDoor make sense?

It is designed for real targets where speed alone is not enough: WAFs, CDNs, soft-404 pages, wildcard routes, restricted resources, authenticated areas, unstable networks, multi-target batches, and transport-controlled scans. Since it first launch in 2016 to the present day, the OpenDoor has changed dramatically, growing from a primitive brute forcer into a new adaptive discovery framework. Became DevOps and QA friendly. OpenDoor focuses on context-aware discovery instead of blind enumeration.

What makes OpenDoor different

Capability Why it matters
Fingerprint-first scanning OpenDoor can identify probable CMS platforms, frameworks, infrastructure providers, and WAF signals before deeper discovery. This helps you scan with context instead of blindly throwing a generic wordlist at the target.
WAF-aware behavior OpenDoor can detect probable WAF / anti-bot behavior and switch to a safer runtime profile with --waf-safe-mode, reducing noisy blocked scans and making defensive responses easier to understand.
WAF guard stop condition OpenDoor can stop a scan early when the initial classified responses are overwhelmingly WAF-blocked. This avoids spending long runs on wordlists that only produce repeated edge/WAF block pages.
Controlled bypass evidence OpenDoor can optionally probe blocked 401 and 403 resources with controlled header-injection and path-manipulation variants. It records exact evidence such as bypass type, header or path variant, probe value, original status code, and resulting status code without mutating global scan headers.
Multi-signal auto-calibration OpenDoor does not rely only on status code or response size. It compares multiple response signals such as body hashes, visible text, semantic soft-404 phrases, DOM-token structure, titles, redirects, stable headers, word count, line count, text density, normalized dynamic tokens, and DNS wildcard baselines to reduce soft-404 and wildcard false positives.
Bounded same-origin crawl --crawl can enrich directory scans with one-hop same-origin links found in already scanned HTML responses. It uses the existing scan pipeline, global request deduplication, per-bucket report deduplication, and bounded memory caps instead of becoming a spider or browser renderer.
Heuristic sniffer plugin system OpenDoor includes a pluggable response-analysis layer for heuristic sniffers such as secrets, stack traces, directory listings, malware indicators, shadow copies, suspicious files, open redirects, and repeated soft-error templates. This lets scans surface meaningful evidence from response bodies instead of reporting only status codes and sizes.
Transport-level workflows OpenDoor supports direct, proxy, OpenVPN, and WireGuard transport modes. It can also rotate transport profiles per target in authorized batch scans, which is not the same as manually starting a VPN before running a scanner.
Proxy pool support OpenDoor can use proxy pools through --proxy-list, validate available proxies before scanning, rotate requests across the live pool. This helps long authorized scans survive unreliable routes without hardcoding a single proxy endpoint.
Fault-tolerant scan runtime OpenDoor is designed to keep scans useful on unstable targets and unreliable networks. It combines request retries, consecutive failure protection, recoverable transport-error handling, proxy rotation, WAF-aware stop conditions, checkpoint sessions, and interactive pause/resume controls so long scans can fail safely instead of silently losing coverage.
Resumable long scans OpenDoor can save scan checkpoints and resume later. This matters when scans are interrupted by crashes, unstable networks, blocked routes, terminal disconnects, or long multi-target jobs.
Runtime pause/resume Press Ctrl+C once during a scan to pause workers, then choose C to continue or E to abort without involving session files.
Differential report comparison OpenDoor can compare a previous and current SQLite/JSON report with --diff old:new, showing added, removed, and changed findings without rescanning the target. This turns scan reports into release-to-release exposure regression checks.
CI/CD-ready results OpenDoor can return a failing exit code only when selected result buckets are found, making it usable as a release gate or exposure regression check without custom post-processing scripts.
Auditable engineering OpenDoor is maintained with multi-platform CI, coverage checks, package checks, documentation builds, and a large unittest suite, making it easier to audit, contribute to, and depend on.

🧬 Recognized technologies

OpenDoor includes a heuristic fingerprint engine for detecting probable application stacks, CMS platforms, frameworks, site builders, static-site tooling, infrastructure providers, HSTS / preload readiness, and WAF / anti-bot systems.

Category Examples
CMS WordPress, Drupal, Joomla, TYPO3, GravCMS, Open Journal Systems, InstantCMS, DiafanCMS, CMS.S3 / Megagroup, Discuz!, NetCat
E-commerce Magento, WooCommerce, Shopify, PrestaShop, OpenCart, Shopware, Webasyst / Shop-Script
Frameworks / app platforms Laravel, Symfony, Django, Flask, FastAPI, Express, NestJS, Next.js, Nuxt, Rails, Spring
Runtime / language stack PHP, Node.js, JavaScript, Python, Ruby, .NET, Java/JVM, Elixir, static-site targets
Site builders Wix, Webflow, Squarespace, Tilda, Duda, Hostinger Website Builder
Static / docs generators MkDocs, Docusaurus, Hugo, Jekyll, VitePress
Infrastructure / hosting Cloudflare, AWS, Vercel, Netlify, GitHub Pages, GitLab Pages, Heroku, Azure, Google Cloud, Fastly, Akamai, Hostinger, DDoS-Guard, Tencent Cloud
Infrastructure / servers Nginx, Apache HTTP Server, Microsoft IIS, Caddy, LiteSpeed, lighttpd, Tornado, Gunicorn, Uvicorn, Hypercorn, Waitress, Apache Tomcat, Eclipse Jetty, Envoy, Traefik
WAF / anti-bot Cloudflare, AWS WAF, Azure Front Door, Akamai, Imperva, Sucuri, ModSecurity, DataDome, Kasada, BunkerWeb, F5 BIG-IP ASM
Security headers HSTS presence, max-age, includeSubDomains, preload directive, local preload readiness

Full list of supported technologies: Fingerprinting technologies

Run fingerprint detection:

opendoor --host https://example.com --fingerprint

After the fingerprint pass finishes, OpenDoor prints a compact pre-scan summary before dictionary enumeration starts:

Fingerprint result: cms/WordPress (95%)
Web stack: WordPress | PHP | Cloudflare
Security posture: HSTS preload-ready

Read more:

📦 Installation

pipx

Recommended for most CLI users:

pipx install opendoor

pip

python3 -m pip install --upgrade opendoor

Windows / Chocolatey

OpenDoor is available from the Chocolatey Community Package Repository:

choco install opendoor -y

Chocolatey packages can lag the latest GitHub/PyPI release while community moderation completes.

Arch Linux / AUR

OpenDoor is available in the Arch User Repository:

yay -S opendoor

Homebrew

OpenDoor is also available in the Brew package manager:

brew install opendoor

Docker

OpenDoor is available as an official project Docker image via GitHub Container Registry.

docker pull ghcr.io/stanislav-web/opendoor:latest
docker run --rm -it ghcr.io/stanislav-web/opendoor:latest --version

Run a scan and write reports to the host:

mkdir -p reports

docker run --rm \
  -v "$PWD/reports:/work/reports" \
  ghcr.io/stanislav-web/opendoor:latest \
  --host https://example.com \
  --reports json,html \
  --reports-dir reports

BlackArch Linux

OpenDoor is available in BlackArch Linux:

sudo pacman -Syu
sudo pacman -S opendoor

From source

git clone https://github.com/stanislav-web/OpenDoor.git
cd OpenDoor

python3 -m pip install -r requirements.txt
python3 opendoor.py --help

See the full installation guide.


🚀 Quick usage

Basic directory scan

opendoor --host https://example.com

Crawl same-origin links

opendoor --host https://example.com --crawl

--crawl is opt-in and only works with directory scans. It uses GET, extracts conservative HTML attributes from already scanned responses, keeps same-origin URLs only, respects ignored extensions, skips POST forms and external origins, and reports discovered URLs through the normal result buckets.

Subdomain scan

opendoor --host example.com --scan subdomains

Target list

opendoor --hostlist targets.txt

Target files may mix URLs, domains, IPv4 addresses, IPv4 CIDR blocks, and inclusive IPv4 ranges:

https://example.com
app.example.com
192.168.1.10
192.168.1.0/24
192.168.1.10-192.168.1.50

Standard input

cat targets.txt | opendoor --stdin

The same mixed target format is supported through STDIN.

Low-noise scan

opendoor \
  --host https://example.com \
  --method GET \
  --auto-calibrate \
  --include-status 200-299,301,302,403 \
  --exclude-status 404,429,500-599 \
  --exclude-size-range 0-256 \
  --sniff endpoint,secret,shadow,openredirect,malware,skipempty,collation,indexof,file,stacktrace \
  --reports std,json,csv,sarif

Response sniffers

Response sniffers classify interesting response bodies during discovery. They are useful when status code and size are not enough to understand what was found.

opendoor \
  --host https://example.com \
  --method GET \
  --sniff endpoint,secret,shadow,openredirect,malware,stacktrace,indexof,file,collation \
  --reports std,json,csv,html,sqlite,sarif

Useful sniffers include:

Sniffer Purpose
indexof Detect directory listing pages.
file Detect known sensitive file exposure patterns.
collation Detects repeated or redirect-like fallback responses that can create false positives.
skipempty Skip empty responses.
skipsizes=46 Skip responses with exact known noisy sizes.
skipsizes=46:1024 Skip responses inside a noisy size range.
stacktrace Detect exposed debug/runtime stack traces and internal error details.
secret Detect possible exposed API keys, tokens, private keys and credentials with redacted report metadata.
shadow Actively probe confirmed 200 OK file-like hits for bounded backup/shadow variants such as .bak, .old, and path templates .
openredirect Actively verify redirect-like query parameters with controlled marker URLs and report only confirmed open redirect vulnerabilities.
endpoint Passively detect client-exposed WebSocket, Socket.IO, SSE/EventSource and AJAX endpoints from already-fetched responses.
malware Detect possible malicious content, webshell markers, injected scripts or obfuscated payloads.

Body-dependent sniffers automatically force GET internally when the configured method is HEAD.

Read more: Sniffers reference

Authenticated scan from raw request

opendoor \
  --raw-request request.txt \
  --scheme https \
  --method GET \
  --auto-calibrate \
  --reports json,html,sqlite,sarif

WAF-safe scan

opendoor \
  --host https://example.com \
  --waf-safe-mode \
  --timeout 60 \
  --retries 5 \
  --delay 0.5

Fault-tolerant scan

Use a more conservative runtime profile for unstable targets, slow networks, temporary WAF blocks, proxy instability, or long-running authorized scans.

opendoor \
  --host https://example.com \
  --method GET \
  --timeout 60 \
  --retries 5 \
  --retries-fail-streak 25 \
  --auto-calibrate \
  --waf-detect \
  --waf-guard \
  --session-save session.json \
  --reports std,json,html

This profile makes scans more resilient by increasing per-request timeout and retry tolerance, limiting aborts to repeated exhausted paths, filtering soft-404 and catch-all responses with auto-calibration, stopping low-value scans when WAF-blocked responses dominate, and saving checkpoint state for later resume.

Resume the scan later:

opendoor --session-load session.json

During an active scan, press Ctrl+C once to pause workers, then choose C to continue or E to abort.

Header and path bypass probes

Use this only on systems you are authorized to test. The feature is opt-in and probes blocked resources with controlled temporary headers and safe path variants.

opendoor \
  --host https://example.com \
  --method GET \
  --waf-detect \
  --header-bypass \
  --header-bypass-limit 32 \
  --reports std,json,csv,sarif,sqlite

When --header-bypass is enabled, OpenDoor first tries configured header-injection variants and then safe path-manipulation variants such as trailing slash, dot segment, semicolon suffix, case variation, and URL-encoded segment. Customize trigger statuses, trusted IP values, and headers:

opendoor \
  --host https://example.com \
  --method GET \
  --header-bypass \
  --header-bypass-status 401,403 \
  --header-bypass-ips 127.0.0.1,10.0.0.1 \
  --header-bypass-headers X-Original-URL,X-Rewrite-URL,X-Forwarded-For,X-Real-IP \
  --reports json,html,sqlite,sarif,csv

Proxy routing

Use a single explicit proxy:

opendoor --host https://example.com --proxy socks5://127.0.0.1:9050

Use the bundled rotating proxy pool:

opendoor --host https://example.com --proxy-pool

Use a custom rotating proxy list:

opendoor --host https://example.com --proxy-list proxies.txt

OpenVPN transport

opendoor \
  --host https://example.com \
  --transport openvpn \
  --transport-profile ./profile.ovpn

If OpenVPN is installed outside PATH, pass the backend explicitly:

opendoor \
  --host https://example.com \
  --transport openvpn \
  --transport-profile ./profile.ovpn \
  --transport-bin /opt/homebrew/sbin/openvpn

On Windows, --transport-bin can point to C:\Program Files\OpenVPN\bin\openvpn.exe. If a GUI client or corporate VPN agent already owns the tunnel, start that VPN outside OpenDoor and run OpenDoor in direct mode.

WireGuard transport

opendoor \
  --host https://example.com \
  --transport wireguard \
  --transport-profile ./profile.conf

More examples:


Differential report comparison

OpenDoor can compare exactly two previous/current reports without running a new scan. Use this when you want to see what appeared, disappeared, or changed between two authorized scan results.

Supported input pairs are SQLite-to-SQLite and JSON-to-JSON only. Mixed formats, missing files, invalid reports, and unsupported report types fail with a graceful validation error.

opendoor --diff reports/baseline/example.com.sqlite:reports/current/example.com.sqlite --reports std,json
opendoor --diff reports/baseline/example.com.json:reports/current/example.com.json --reports std,json --reports-dir ./diff

SARIF reports for CI/CD

OpenDoor can export findings as SARIF 2.1.0 for GitHub Code Scanning and SARIF-compatible security pipelines.

opendoor \
  --host https://example.com \
  --reports sarif,json \
  --reports-dir ./reports

GitHub Actions upload example:

- name: Upload OpenDoor SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: reports/example.com/example.com.sarif
    category: opendoor

🎓 Mastering OpenDoor

Hands-on article series for learning OpenDoor through reproducible, authorized web reconnaissance workflows.

OpenDoor

📚 Documentation

The full documentation is available on ReadTheDocs:


🧪 Development

Install development dependencies:

python3 -m venv .venv
source .venv/bin/activate

python -m pip install --upgrade pip setuptools wheel
python -m pip install -r requirements-dev.txt
python -m pip install -e .

Run tests:

python -m unittest

Run coverage:

coverage run -m unittest discover -s tests -p "test_*.py"
coverage report -m

Build documentation:

python3 -m venv .docs-venv
source .docs-venv/bin/activate
python -m pip install -r docs/requirements.txt
python -m mkdocs build --strict

Build package artifacts:

python -m build

See the full testing guide and contribution guide.


🔐 Security and secret hygiene

Do not commit real secrets or private transport profiles.

Never publish:

  • real OpenVPN profiles;
  • WireGuard private keys;
  • mTLS client certificates and private keys;
  • auth-user-pass files;
  • cookies;
  • bearer tokens;
  • customer target lists;
  • private scan reports;
  • sensitive CI artifacts.

Use placeholder examples only.


⚖️ Responsible use

OpenDoor is a security testing tool.

Use it only against systems you own or have explicit permission to test.

Features such as WAF detection, WAF-safe scanning, raw request replay, transport profiles, and Header Injection Bypass probes are intended for authorized security testing, defensive validation, and exposure regression checks.

The project does not grant permission to scan third-party systems, organizations, commercial services, or public infrastructure without authorization.


🧾 Changelog

See CHANGELOG.md and GitHub Releases.


🤝 Contributing

Pull requests are welcome.

Before contributing, read the contribution guide and run the relevant tests. OpenDoor improves through code contributions, documentation updates, testing, issue reports, security feedback, feature ideas, and community validation. Thanks to everyone who has helped improve the project.

Contributors


📄 License

OpenDoor is released under the GNU General Public License v3.0 only.

See LICENSE.


Support

If OpenDoor helps your authorized security work, you can support ongoing maintenance through Giveth.

Support OpenDoor on Giveth


Ask DeepWiki License: GPL v3

Frequently asked questions

Is OpenDoor free to use?

OpenDoor is open source under the GPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does OpenDoor do?

OWASP Web Recon & Directory Discovery Platform

What is OpenDoor written in?

OpenDoor is primarily written in Python. Its source is publicly available at https://github.com/stanislav-web/OpenDoor, and it has 1,008 GitHub stars.