# WebHackersWeapons: a curated index of web hacking tools, not a toolkit > WebHackersWeapons is a Ruby-generated catalogue of tools, bookmarklets, browser addons and proxy extensions used in web hacking and bug bounty work. It organises other people's software by type, tag and language; it does not install or run any of it. **hahwul/WebHackersWeapons** — ⚔️ Web Hacker's Weapons / A collection of cool tools used by Web hackers. Happy hacking , Happy bug-hunting - Repository: https://github.com/hahwul/WebHackersWeapons - Stars: 5,087 · Forks: 851 - Language: Ruby - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/hahwul-webhackersweapons ## What WebHackersWeapons actually is The README opens with a single line: "A collection of awesome tools used by Web hackers." That is the entire product. WebHackersWeapons is a catalogue, not an application. It gathers links to other people's software and sorts them into tables you can browse, and the repository's own description frames it as a collection rather than a suite. The audience is narrow and specific. It is written for people doing web application testing and bug bounty hunting who already know roughly what phase of work they are in (recon, fuzzing, exploitation) and want to see what tools exist for that phase. If you are looking for a single binary that performs reconnaissance, this is the wrong repository. Nothing here executes against a target. The scope is broader than the name suggests. Alongside command line tools, the table of contents lists Bookmarklets, Browser Addons, and a section titled "Burpsuite, Caido and ZAP Addons." The family project section links to MobileHackersWeapons, a separate repository for mobile work, which tells you the maintainer treats web and mobile as distinct catalogues rather than one merged list. ## How the catalogue is structured: types, tags and languages Every entry carries three attributes. Types are a closed set of nine: Army-Knife, Proxy, Recon, Fuzzer, Scanner, Exploit, Env, Utils and Etc. Tags are an open, much longer set, each linking to a page under categorize/tags/ such as live-audit, mitmproxy, crawl, osint, subdomains, jwt, prototype-pollution, ssti and zipbomb. Languages are listed under categorize/langs/ and cover Go, Java, Python, Ruby, Shell, JavaScript, Rust, C, Crystal, Kotlin, Perl, C#, TypeScript, HTML, BlitzBasic, C++, CSS, Txt and PHP. The tool table itself has six columns: Type, Name, Description, Star, Tags and Badges. The Star column renders a GitHub star badge per project. That is worth flagging plainly: a star count in that column is a popularity signal for the linked project, and the repository uses it as a sortable attribute, not as a quality score. Treat it as a hint about how many people have looked at a tool, nothing more. The categorize/ directory is the part that does real work. Because tags and languages are materialised as separate files, you can browse a single dimension without reading the whole table. If you know you want something written in Go that deals with subdomains, the tag and language pages let you intersect those interests manually. The README does not document a query interface or a search command, so that intersection is a browsing exercise rather than a programmatic one. ## Cloning WebHackersWeapons and reading your first entry There is no install step in the usual sense. The README does not give a package manager command, a binary, or a version to pin. The project is consumed by cloning the repository and reading it, and the primary language reported for the repository is Ruby, which is the language of the scripts that generate the tables rather than something you run against a target. The README itself gives no clone command, so the only commands shown here are the ones a reader would need to open the repository locally and inspect its directories. After cloning, look at the layout first. The two directories that matter for a reader are weapons/ and categorize/. ```bash git clone https://github.com/hahwul/WebHackersWeapons.git cd WebHackersWeapons ls ``` After that command you should see the top-level entries the repository documents: .github/, .gitignore, .yamllint.yml, AGENTS.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE, README.md, SECURITY.md, categorize/, images/, scripts/ and weapons/. The weapons directory holds the tool listings, and categorize splits into tags and langs. If you want to check whether a specific tool is catalogued before you go looking for it elsewhere, read the table rather than scrolling a long README. The README's own worked example is jaeles, described there as "The Swiss Army knife for automated Web Application Testing" and typed as Army-Knife. A match tells you the tool is listed and which type and tags it carries. It does not tell you the tool is installed, current, or safe to run, because WebHackersWeapons does not vendor any of these projects. If you intend to contribute an entry rather than consume one, the README points at CONTRIBUTING.md, and the repository also carries AGENTS.md, CODE_OF_CONDUCT.md and SECURITY.md at the top level. The .yamllint.yml file at the root suggests the listing data is linted as YAML, so a contribution that breaks YAML formatting will likely fail before review. ## The failure mode: a catalogue ages differently from software The central limitation is structural. WebHackersWeapons has no mechanism to verify that a linked tool still works, still exists, or still does what its one-line description claims. Each row is a name, a short description and a link. When an upstream project is abandoned, renamed or archived, the catalogue entry does not change by itself. The tag broken-link appears in the tag list, which suggests the maintainers are aware that dead links are a category worth tracking, but awareness of the problem is not the same as automatic detection. The descriptions are also terse to the point of being unhelpful for selection. "The Swiss Army knife for automated Web Application Testing" tells you the ambition of jaeles, not its coverage, its false positive rate, or whether it suits a single-target manual assessment versus a wide scan. You will have to leave the repository to make that call, which is expected, but it means the catalogue shortens discovery rather than evaluation. The star column invites a specific misuse. Sorting by stars surfaces tools that are popular, which correlates with age and general-purpose appeal, not with fitness for your particular target. A narrowly useful JWT tool with modest visibility may sit far below a broad scanner that everyone has starred. The repository gives you tags and types precisely so you can ignore the star column when it is misleading, and you should. Finally, this is the wrong tool if you want reproducible results. Because it pins nothing and runs nothing, two people reading it on different days may follow different links to different versions of the same underlying project. ## Where it sits against a single-tool approach The obvious alternative is to skip the catalogue and go directly to one established project in the space. A tool like jaeles, which appears in the README as an Army-Knife entry, is a self-contained scanner with its own documentation, releases and issue tracker. If you already know you want signature-based automated web testing, reading jaeles' own repository is more informative than reading its row here, because the row is one sentence and the repository is the actual specification. The difference in approach is discovery versus depth. A single mature tool gives you a maintained codebase, a changelog and a support channel, and it constrains you to one way of working. WebHackersWeapons gives you breadth across nine types and dozens of tags, including bookmarklets and proxy addons that a scanner repository would never mention, at the cost of any depth on any individual entry. A second alternative is a general awesome-list for security. Those tend to be flat, alphabetised or loosely grouped, and they mix network, mobile, binary and web work in one file. WebHackersWeapons is narrower and more structured: it is web-specific, it separates tools from bookmarklets from browser addons from proxy extensions, and it maintains tag pages so a single concept like prototype-pollution or race-condition can be browsed across languages. If your work is web and bug bounty focused, that structure is the reason to prefer it over a general list. ## Maintenance, licence and the cost of upgrading The repository is not archived, and its last push was on 2026-09-07. That is recent enough that the catalogue is being touched, and the README carries a contributions-welcome badge pointing at CONTRIBUTING.md. There are no retrieved releases, which is consistent with a project that has nothing to version: there is no artefact to publish. Upgrade cost is therefore close to zero and also close to meaningless. You pull the main branch and you get whatever the tables say today. There is no migration path, no breaking change to plan for, and no dependency graph to reconcile, because the repository does not depend on the tools it lists. The cost you actually pay is attention: every time you consult it, you are trusting that the entries were accurate when last edited, not when you read them. The licence is MIT, stated in the LICENSE file at the top level. For a catalogue this is generous and uncomplicated: MIT permits reuse and redistribution of the listing content with attribution and without warranty. Note the boundary, though. The MIT licence covers WebHackersWeapons itself. It says nothing about the licences of the tools it links to, and those vary widely, from permissive to restrictive to unlicensed. If you plan to bundle any catalogued tool into something you ship, check that tool's own licence separately. This is a description of what the licence file states, not legal advice. ## Conclusion Adopt WebHackersWeapons if you are assembling a web hacking workflow and want a categorised starting point before you commit to individual tools; the tags and language filters under categorize/ are the fastest way to narrow a long list. Do not adopt it if you need something that scans a target, because it ships no scanner of its own. Before relying on it, open weapons/ and confirm the specific entry you care about is still listed, and check the linked repository for that tool directly, since WebHackersWeapons records what exists rather than vouching for it. ## FAQ ### Does WebHackersWeapons scan a target itself? No. It is a collection of links to tools used by web hackers, sorted by type, tag and language. Running any scan means going to the linked project and installing that separately. ### How do I install WebHackersWeapons? There is no install step documented. You clone the repository and read it; the Ruby language reported for the project refers to the scripts that build the tables, and the README gives no package manager command or binary. ### What are the types used to categorise tools in WebHackersWeapons? The README lists nine types: Army-Knife, Proxy, Recon, Fuzzer, Scanner, Exploit, Env, Utils and Etc. Each entry in the tool table carries one of them alongside tags, a language and a star badge. ### Which website do hackers use? The README does not answer this. WebHackersWeapons is a GitHub repository that links to other tools, and it does not name or rank websites used by hackers. ### What licence does WebHackersWeapons use? MIT, stated in the LICENSE file at the top level. That covers the catalogue itself, not the licences of the individual tools it links to, which vary by project. ## Sources - [hahwul/WebHackersWeapons on GitHub](https://github.com/hahwul/WebHackersWeapons) - [Issues](https://github.com/hahwul/WebHackersWeapons/issues) - [License: MIT](https://github.com/hahwul/WebHackersWeapons/blob/main/LICENSE) - [README](https://github.com/hahwul/WebHackersWeapons/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hahwul-webhackersweapons