The Best Application-Layer DoS Testing Tools in 2026

This is a list of tools I use to test the resilience of systems I own or am authorised to test. Every tool here is framed for load testing, resilience research, and defensive pentest work, the kind of thing you run against your own staging environment, a contracted target, or a lab. None of it is a directory of stresser or booter services, and I will not name any. If you came looking for that, this is not the article.

The goal of an application-layer DoS test is to find the cheap requests that cost the server expensively, before someone else does. A correctly tuned 200 requests per second on the right endpoint will outdo a botnet pointed at your front door, and the fix is almost always in your code, not your edge. That is the work this tooling supports.

If you want the underlying mechanics first, the application-layer DoS deep dive covers the variants, and the web application security vulnerabilities taxonomy places it in the broader map. For one of the classic input-driven amplifications, see the billion laughs attack.

The decision matrix

Quick read: k6 is the default for HTTP load and CI resilience checks. wrk2 is the right answer when you want raw RPS to find expensive endpoints. slowhttptest, recheck, and h2spec each cover one specific failure mode that generic load tools will miss.

1. k6

Repo: github.com/grafana/k6

The default. If you only learn one tool here, learn this one.

k6 is a Go-based load and resilience testing platform from Grafana. You write scenarios in JavaScript, k6 executes them with a Go runtime, and the metrics flow into Prometheus, Grafana Cloud, or whatever you already have. It covers HTTP/1.1, HTTP/2, WebSockets, gRPC, and Browser scenarios via the experimental browser module.

What I like:

• Scenarios are real code, not a GUI plan. Versioned in git next to the service.
• Thresholds are first-class. A http_req_duration over 800 ms fails the run, the CI job fails, the regression never ships.
• Executors cover ramping, constant-arrival-rate, shared-iterations, and per-VU iterations. Constant-arrival-rate is the one for resilience work, it holds RPS steady regardless of how slow the server gets.
• xk6 extensions cover SQL, Kafka, AMQP, and most non-HTTP surfaces.

What I do not like:

• The JS runtime is goja, not Node. Half of npm does not work.
• Browser scenarios are heavier than they look. Treat them as a separate cost class.
• Grafana Cloud k6 pricing scales with VU-hours. Self-hosting is fine for most teams.

When to use it. As the first tool. Resilience checks in CI, soak tests, capacity baselines, regression gates on the latency tail.

2. wrk and wrk2

Repo: github.com/giltene/wrk2

The microscope for finding which endpoints on your own service are cheap to ask and expensive to answer.

wrk is a C-based HTTP benchmarking tool that drives huge request rates from one box. wrk2 is Gil Tene's fork that fixes the "coordinated omission" measurement bug in the original, so the tail-latency numbers you read are honest. For resilience research, that distinction is the whole point.

What I like:

• A single binary saturates most application servers from one laptop.
• Lua scripts let you shape requests cheaply: vary the path, mutate a JSON body, sign a header.
• Honest p99 and p99.9 numbers under sustained rate. You learn which endpoint melts first.

What I do not like:

• No scenarios, no thresholds, no CI integration. A microscope, not a test suite.
• wrk is unmaintained on master; wrk2 is the live fork. Lua, not JavaScript.

When to use it. When you suspect a specific endpoint is the compute-amplifier (a search query, a regex-driven validator, an unbounded sort, a GROUP BY over user input) and you want to confirm the cost shape with raw RPS. Then take the fix back to k6 to lock it in.

3. slowhttptest

Repo: github.com/shekyan/slowhttptest

The slowloris-class resilience checker. Run it against your own origin, not the internet.

slowhttptest holds connections open with deliberately slow headers or slow bodies, the family of issues collectively called slowloris. Sergey Shekyan maintains the canonical Apache-2.0 repository at shekyan/slowhttptest. The classic mitigations (proper read timeouts, per-IP connection caps, an edge that absorbs the slow side) are what the tool exists to validate.

What I like:

• Tests the failure mode generic load tools miss entirely. k6 and wrk2 will not find a missing read timeout because they read fast.
• Sane defaults. Slow-headers (-H), slow-body (-B), and slow-read (-X) modes each map to a real failure class.
• Tiny binary, no runtime weight.

What I do not like:

• Output is plain. You will pipe it through awk or just watch the connection count.
• Genuinely a stress tool. Pointed at the wrong target it is destructive. Staging or contracted only, never shared infrastructure.

When to use it. Once per environment, after any change to the reverse proxy, edge, or web server config. Cheap to run, catches a real class of misconfiguration that nothing else covers.

4. recheck (ReDoS static analyzer)

Repo: github.com/makenowjust-labs/recheck

The right tool for the most under-defended application-layer DoS vector: a regex on user input.

ReDoS is when a pattern with nested quantifiers takes exponential time on a crafted input string. The classic example is ^(a+)+$ against aaaaaaaaaaaaaaaaaaaa!. recheck is a static + dynamic hybrid that flags catastrophic-backtracking and superlinear patterns, including the patterns the older safe-regex package misses.

What I like:

• Catches both true exponential and superlinear (polynomial) blowup. safe-regex flags the obvious cases and misses the subtle ones.
• Has a CLI, a JS library, and editor integrations. Run it in CI on every regex literal in the repo.
• Honest about its analysis budget. When it cannot prove safety inside the budget, it says so rather than passing.

What I do not like:

• False positives exist. Some patterns are theoretically vulnerable but not reachable in practice given the input shape.
• The dynamic-attack-generation mode is slow on large codebases. Use the static mode for CI gating and the dynamic mode for high-value patterns.

When to use it. As a CI step on every commit that touches regex code. As a one-shot audit on a codebase you have inherited. If recheck flags a pattern that handles user input, that bug is sitting on the floor waiting for someone to pick up.

5. h2spec (summerwind) and h2load (nghttp2)

Repos: github.com/summerwind/h2spec · github.com/nghttp2/nghttp2

The HTTP/2 layer the rest of the toolchain does not really cover.

h2spec is a Go-based conformance test suite for HTTP/2 and HPACK by Moto Ishizawa, maintained at summerwind/h2spec (not part of the nghttp2 project). h2load is the nghttp2 project's HTTP/2 and HTTP/3 load generator. The pair matters for resilience because the last two waves of headline HTTP/2 DoS issues (Rapid Reset in 2023, CONTINUATION-flood in 2024) were protocol-level, and your generic HTTP/1.1 load tool will not exercise the affected code paths.

What I like:

• h2spec encodes the spec. If your server fails a conformance test, that is often the same failure mode an abuse case exercises.
• h2load is the right tool for stable HTTP/2 and HTTP/3 RPS measurements. It does not impose HTTP/1.1 mental models on you.
• The pair is small, self-contained, packageable.

What I do not like:

• Documentation is sparse. The codebase is the docs.
• No high-level scenario layer. You compose runs in shell scripts.

When to use it. Whenever your edge or origin terminates HTTP/2 or HTTP/3 directly. After any upgrade to the HTTP/2 stack (nginx, Caddy, Envoy, h2o, the language-level server you embed). And specifically when a new HTTP/2 abuse case lands and you need to validate your patch level.

6. Burp Suite with Turbo Intruder

Site: portswigger.net/burp

The right environment when the test is part of a broader pentest, not a standalone load run.

Turbo Intruder is the PortSwigger extension that drives high-rate requests from inside Burp. The benefit is not raw throughput; k6 and wrk2 will beat it on numbers. The benefit is context. You already have the authenticated session, the cookies, the request shape, the response decoder. You move from a Repeater request to a 1,000-RPS probe in one keystroke.

What I like:

• Reuses the Burp workflow end to end. No re-auth, no scenario rewrite.
• Python scripting model is approachable for the small custom abuse case.
• Excellent for the "is this endpoint cheap to request, expensive to answer" question inside an engagement.

What I do not like:

• Burp Pro licence cost is real. Around 500 USD per user per year.
• Not the right tool for sustained load. It is a probe, not a soak.

When to use it. Inside a pentest engagement, on a specific endpoint, when you already have an authenticated session you do not want to re-create in another tool.

7. Locust

Repo: github.com/locustio/locust

The Python answer when k6 scenarios cannot express what you need.

Locust is a Python-native load tool with a web UI. You define user behaviour as a Python class, Locust runs swarms of those users at the target. It overlaps heavily with k6, and on a greenfield project I will reach for k6 first, but Locust wins when the scenarios need real Python: a shared client library, a custom protocol, a complex auth flow that already exists in a Python codebase.

What I like:

• Scenarios are plain Python. The whole language is available, not a JS subset.
• The web UI for live test runs is genuinely good for non-engineer audiences.
• Distributed mode is straightforward to wire up.

What I do not like:

• Lower ceiling than k6 on raw RPS per machine. Python GIL is the limit. Scale horizontally.
• Smaller protocol coverage out of the box. HTTP is excellent, anything else you write yourself.

When to use it. When you already live in a Python stack, when the scenario logic is genuinely complex, or when the audience for the load run is non-engineer and the live UI matters.

8. OWASP ZAP (attack mode + scripting)

Site: zaproxy.org

The free intercepting proxy with a scripting story strong enough to be a resilience tool.

ZAP is the OWASP-led open-source alternative to Burp. For DoS-adjacent work the value is the scripting engine plus CI integration: you can encode an abuse case as a script, run it in headless ZAP from a CI job, and gate releases on it. Not as polished as Burp, but it is free and it automates cleanly.

What I like:

• Free, properly free, no licence-tier tax on CI runners.
• The ZAP automation framework is genuinely usable from a CI pipeline.
• Active project, regular releases.

What I do not like:

• The UI is rougher than Burp. The manual pentest workflow is slower.
• Some attacks in the built-in scanner are blunt. Tune carefully before pointing at staging, and never at production.

When to use it. As the CI-integrated resilience checker when budget rules out Burp Pro across the team. As a complement to k6 for the abuse-case-shaped tests that are easier to express as a security scan than as a load scenario.

What I do not recommend

Stresser and booter services

There is a class of paid services that advertise "stress testing" via attack capacity rented by the minute. They are not in this list and I will not name any. In practice they are used almost exclusively against systems the buyer does not own, the operators are routinely indicted, and using them against any third party is a criminal offence in every jurisdiction I am aware of. Even pointed at your own infrastructure they are the wrong tool: you have no insight into the traffic shape, no way to make the test deterministic, and you are paying someone whose business model is criminal. Run k6 or wrk2 against your own staging; you will learn more and you will not be a customer of a crime syndicate.

Random "DDoS scripts" from GitHub

The python files with names along the lines of "ultimate-http-flooder" are not load testing tools. They are bait. Read them and you find half are obviously broken, the other half exfiltrate or carry a backdoor, and none of them produce a measurement you can act on. Use the maintained tools above.

Tools I dropped from this year's list

• Apache JMeter. Not abandoned, but for new work I reach for k6 every time. The XML scenario format and Java memory footprint are no longer worth it.
• Apache Bench (ab). Useful for a thirty-second smoke test; coordinated-omission bug, no HTTP/2, no scenarios. Use wrk2 instead.
• Siege. Similar story. Replaced in my workflow by k6 and wrk2.
• Goldeneye, hulk, pyloic, and the "low orbit ion cannon" family. These are stresser-class tools dressed as test scripts. Not on this list, will not be on a future list.

Which tool should I use? (Decision tree)

A short flow for the common cases:

• You want a resilience check in CI that fails the build on a latency regression.
  • k6 with thresholds.
• You suspect one specific endpoint is the compute amplifier and you want raw RPS to confirm.
  • wrk2.
• You are worried about slow-header or slow-body connection exhaustion on your edge.
  • slowhttptest, against your own staging or contracted target only.
• Your service handles user-supplied regex, or runs regex on user input.
  • recheck, in CI.
• Your origin terminates HTTP/2 or HTTP/3 and you want to validate against Rapid Reset, CONTINUATION-flood, and the next protocol-level abuse case.
  • h2spec for conformance, h2load for sustained measurement.
• You are inside an authorised pentest and want a single-endpoint probe against an authenticated session.
  • Burp with Turbo Intruder.
• Your scenario logic is already in Python and porting it to k6 JS is not worth it.
  • Locust.
• You need a CI-integrated abuse-case scanner and Burp Pro is not affordable across the team.
  • OWASP ZAP automation framework.

A note on the year stamp

I refresh this list every twelve months. The slug stays stable (best-application-layer-dos-tools-2026 is the canonical entry; future years update the H1, title, and the dropped-tools list). The decision tree changes more than the matrix, because the protocols change faster than the testing model does.

Where to go next

• Application-layer DoS: variants, exploitation, and defence for the underlying mechanics
• Web application security vulnerabilities taxonomy for where DoS fits in the broader map
• The billion laughs attack for the classic input-driven amplification