# NoMore403: a scanner for access-control bypasses that starts with a baseline

> nomore403 is a Go command line tool that tests whether a 401 or 403 response can be evaded by mutating the request path, method, headers or wire format, and it calibrates against the target's own default error behaviour before scoring the results. It is built for authorised testing, and it is explicit that the scoring is heuristic rather than proof.

**devploit/nomore403** — 🚫 Advanced tool for security researchers to bypass 403/40X restrictions through smart techniques and adaptive request manipulation. Fast. Precise. Effective.

- Repository: https://github.com/devploit/nomore403
- Stars: 1,900 · Forks: 220
- Language: Go
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/devploit-nomore403

## Everything is compared against the blocked response you already got

The nomore403 command line tool is for testing HTTP access-control bypasses and parser inconsistencies around 401, 403 and related responses. The README is explicit about the intended setting: bug bounty, penetration testing, security reviews, and regression testing of access-control rules.

The design decision that makes it different from a generic fuzzer is the baseline. Given a target URL, the tool sends a baseline request to capture the blocked response, optionally auto-calibrates against non-existent paths to learn the target's default error behaviour, runs a set of bypass techniques that mutate the request path, method, headers or wire format, scores and groups the results to reduce noise, and emits replayable evidence including curl commands for interesting findings.

That ordering is the whole point. A raw request mutation tool produces a pile of responses, and most of them are 403, 404 or 400 responses that mean nothing. A tool that knows what the target's default 404 looks like, and what its block page looks like, can drop the responses that are just the server being a server, and keep the one where a header injection turned a 403 into a 200 with a different body.

The README also draws a line that is worth repeating: this tool does not break authentication by itself. It helps find differences between how frontends, proxies, WAFs, CDNs, application routers and backends interpret the same request. A difference in interpretation is a bug in the stack, and finding it is the job.

The audience is a security engineer or a developer who owns the access-control rules and wants them tested the way a researcher would test them.

## Auto-calibration is what stops a 404 from looking like a bypass

The false positive problem in access-control testing is specific, and the calibration is the answer to it.

A server that returns 404 for /admin/nonexistent might also return 404 for a mutated path, and a server that returns a redirect to a login page might do so for the baseline and for the mutation alike. Without a reference point, both look like findings. The tool therefore sends requests to several non-existent paths and builds a baseline for the target's default error behaviour, and it also performs a fragment-based calibration request to reduce false positives caused by fragment-stripped paths.

Calibration is enabled by default in non-verbose mode, and the flags let you change its behaviour. The --no-calibrate flag compares only against the default blocked response, which is the right choice when you already know the target's error pages and want a clean run. The --strict-calibrate flag also compares body hash and key headers such as Location, Content-Type and Server.

That last one deserves attention, because it is where the false positives really live. A response of the same length with a different Server header, or the same body with a different Content-Type, is a different response. A tool that only compares status codes and lengths will call that a finding, and the person reading the report will spend an hour on it.

The example output in the README shows calibration in action, with a line reporting the 404 baseline size, a tolerance figure and a fragment size, which is the calibration data rather than a result.

## The score ranks candidates and never claims proof

The scoring model is documented in enough detail to be argued with, and the README's framing is the important part: scoring is heuristic, intended to prioritize results, not to prove exploitation.

The tool rewards transitions to 2xx and 3xx, large body length changes, body hash changes, Location changes, anomalous redirects that do not appear to resolve into a login or denied flow, and differences that survive replay. It down-ranks near-identical responses, repeated parser noise, unstable replay results, empty-body redirects that appear to lead back into access control, and many 400 and 404 cases unless the response also changes substantially.

The interpretation guide is three levels. HIGH is likely actionable and should be reviewed first. MED is a plausible candidate, usually worth manual replay. LOW is a parser difference, a routing anomaly, or lower-confidence behaviour.

Two transition rules are worth memorising, because they decide whether you have anything. A 403=>200 usually deserves immediate attention. A 403=>302 can be interesting but may still resolve back into an auth barrier, which is exactly the case that produces the most wasted time if you only look at the status code. And a 403->400 or 403->404 usually indicates parser or routing differences rather than a bypass.

The last two of those are the reason the summary sections are split. At the end of a run, the tool prints LIKELY BYPASS with the highest scoring results and reproducible curl commands, and INTERESTING VARIATIONS with meaningful parser or routing differences that are worth manual review, and it reports how many techniques ran but produced no visible output after filtering. That last count is a useful honesty signal, because a technique set that produced nothing visible is different from a target with no bypassable path.

## Some techniques need curl and a real socket, not net/http

The request manipulation has two layers, and the tool is candid about which techniques fall into the harder layer.

Raw HTTP support exists for request forms that net/http normalizes away. Go's standard HTTP client rewrites paths, tidies headers and refuses some malformed requests, so a technique that depends on an odd request line or an unusual header layout cannot be expressed through it. The tool keeps a raw path for those cases.

Separately, curl has to be available in PATH for the techniques that depend on it, and the README names them: http-versions, http-parser and absolute-uri. Most techniques work without curl, which is a useful distinction, because curl is the one external binary in the picture and it is the difference between a self-contained Go binary and a Go binary with a dependency on the host.

That dependence has a consequence for packaging. The payloads directory is where the request variations live, and if you install with go install the payloads/ directory is not installed automatically. The README tells you to clone the repository and point the tool at that directory with -f if needed. It is the kind of detail that turns a one line install into a half working one on a machine where you do not have the repository checked out.

The technique set itself is selected with -k, which takes a comma separated list, and the README's example runs headers, absolute-uri and raw-desync. A targeted run is much more useful than a full run when you are chasing one specific parser quirk, because the output stays readable.

## Two install routes, and one of them loses the payloads

Building from source is three commands in the repository root:

```bash
git clone https://github.com/devploit/nomore403
cd nomore403
go build
```

The alternative is the Go toolchain install:

```bash
go install github.com/devploit/nomore403@latest
```

The README states the caveat immediately after: if you install with go install, the payloads/ directory is not installed automatically, and you should clone the repository and point the tool at that directory with -f if needed. Requirements are Go 1.24 or later to build from source, and curl in PATH for the techniques that need it.

The first run is a single target and a flag:

```bash
./nomore403 -u https://target.tld/admin
```

Everything else is variation on that. A proxy and verbose output add -x and -v, the technique subset is chosen with -k, and targets can come from a file or from standard input:

```bash
cat urls.txt | ./nomore403
```

A Burp style request file is also accepted, with --request-file request.txt, which is how you replay a request that a proxy captured rather than composing one from a URL.

The one thing to settle before any of this is authorisation. The tool's own feature list names bug bounty and penetration testing, and its techniques are attempts to defeat access controls. Running it against infrastructure you have not been given written permission to test is a different activity from the one the project describes, and the permission question is not a formality.

## JSONL output is what makes it usable in a pipeline

The tool is not only for a human at a terminal, and the input and output sides show that.

On the input side, targets can come from a single URL, URL files, standard input, or request files. On the output side, the tool supports JSON and JSONL output for pipelines and post-processing, with the JSONL example writing straight to a file:

```bash
./nomore403 -u https://target.tld/admin --jsonl -o findings.jsonl
```

That combination is the reason to care about this tool if you already run a scanning pipeline. Findings become records rather than screen output, so a second stage can re-verify them, attach them to a ticket, or compare them against a previous run to detect a regression in your own access-control rules.

The other feature that matters for repeatability is replay. The README lists replay and reproducibility for high-value findings as a feature, and the scoring model explicitly rewards differences that survive replay while down-ranking unstable results. A finding that only reproduces once, in the right conditions, with a race, is not a finding yet, and the tool's own scoring reflects that.

Concurrency and resilience are handled too. The tool runs techniques concurrently with per-technique progress, and it has retry and backoff for transient network failures, which matters when the target is a distributed stack where one node is slower than the others.

The implementation is compact for what it does. The module dependencies are few: cobra for the command line, viper for configuration, fatih/color for terminal output, goccm for the concurrent work, and golang.org/x/term for terminal handling. The repository has a cmd directory, a main.go, a payloads directory, and a .goreleaser.yaml for building the binaries.

## MIT licensed, Go 1.24, and a v2 line released in a single afternoon

The licence is MIT, with the LICENSE file at the root of the repository, and the README carries an MIT badge. There is no copyleft obligation on a tool that a security team runs internally or wires into a scanning pipeline.

The release history is worth a close look because it shows a v2 boundary. Version 1.4.0 was published on 2026-04-12 at 13:11, v2.0.0 at 21:48 the same day, and v2.0.1 at 23:48 the same day. A major version and a patch release inside a single afternoon is a signal that the 2.0 boundary was a deliberate reset, and if you are migrating from 1.x you should read the release notes rather than assume the flags carried over.

The last push to the repository was on 2026-06-21, and the project is not archived. The Go version requirement in go.mod is 1.24.0, matching the README's stated requirement of Go 1.24 or later.

The repository is organized like a serious tool rather than a script. There is a cmd directory and a main.go, a payloads directory holding the request variations, a go.mod and go.sum, a .goreleaser.yaml for release builds, a SECURITY.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and a .github directory for the workflows.

One dependency detail is worth knowing if you vendor it. The go.mod lists goccm for concurrency, and the indirect dependencies include fsnotify and viper's config loader, which is how a tool like this reads a configuration file and a directory of payloads without pulling in a large framework.

## Conclusion

NoMore403 fits an authorised security tester who needs to prove or disprove that an access-control rule can be evaded, and a team that wants to run that check as a regression test in a pipeline. It does not fit an unscoped scan of third-party infrastructure, since every technique it runs is an attempt to defeat an access control that someone put there on purpose, and it does not replace manual review, because the README states the scoring is heuristic and prioritises results rather than proving exploitation. Before you run it, confirm in writing that the target is in scope, install curl and point the tool at the payloads directory if you installed with go install, and treat every HIGH finding as a candidate to replay rather than a confirmed bypass.

## FAQ

### What does nomore403 do and who is it for?

It is a command line tool for testing HTTP access-control bypasses and parser inconsistencies around 401 and 403 responses, built for bug bounty work, penetration testing, security reviews and regression testing of access-control rules. It does not break authentication by itself, it finds differences between how the components in front of a request interpret it.

### How do I install nomore403?

Build from source with git clone, cd nomore403 and go build, or install with go install github.com/devploit/nomore403@latest. Go 1.24 or later is required, and if you install with go install the payloads directory is not installed automatically, so you should clone the repository and point the tool at it with -f.

### What does auto-calibration do in nomore403?

It sends requests to several non-existent paths to build a baseline of the target's default error behaviour, and performs a fragment-based calibration request, both of which reduce false positives. It is enabled by default in non-verbose mode and can be changed with --no-calibrate or --strict-calibrate.

### Does a HIGH score in nomore403 mean a bypass was confirmed?

No. The README states that scoring is heuristic and is intended to prioritize results, not to prove exploitation. A HIGH result is likely actionable and should be reviewed first, MED is a plausible candidate worth manual replay, and LOW is a parser difference or lower-confidence behaviour.

### Why does nomore403 need curl installed?

Curl has to be available in PATH for the techniques that depend on it, which the README lists as http-versions, http-parser and absolute-uri. Most techniques work without curl, and the tool also supports raw HTTP for request forms that net/http normalizes away.

## Sources

- [devploit/nomore403 on GitHub](https://github.com/devploit/nomore403)
- [Issues](https://github.com/devploit/nomore403/issues)
- [License: MIT](https://github.com/devploit/nomore403/blob/main/LICENSE)
- [README](https://github.com/devploit/nomore403/blob/main/README.md)
- [Releases](https://github.com/devploit/nomore403/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devploit-nomore403