|
| 1 | +# Contributing to NoMore403 |
| 2 | + |
| 3 | +Contributions are welcome. Useful areas include bug fixes, better payloads, new bypass techniques, raw HTTP improvements, frontend fingerprinting, tests, and documentation. |
| 4 | + |
| 5 | +## Responsible Use |
| 6 | + |
| 7 | +NoMore403 is intended for authorized security testing, bug bounty work, penetration testing, security reviews, and regression testing. |
| 8 | + |
| 9 | +Do not include private target data, credentials, tokens, customer data, or non-public vulnerability details in issues, pull requests, commits, tests, fixtures, or screenshots. Redact real hostnames unless they are intentionally public test targets. |
| 10 | + |
| 11 | +If you need to report a vulnerability in NoMore403 itself, follow [SECURITY.md](SECURITY.md). |
| 12 | + |
| 13 | +## Development Setup |
| 14 | + |
| 15 | +Requirements: |
| 16 | + |
| 17 | +- Go 1.24 or later |
| 18 | +- `curl` in `PATH` for techniques that exercise curl-based request behavior |
| 19 | + |
| 20 | +Build and test locally: |
| 21 | + |
| 22 | +```bash |
| 23 | +go test ./... |
| 24 | +go build ./... |
| 25 | +``` |
| 26 | + |
| 27 | +Before opening a pull request, format Go code: |
| 28 | + |
| 29 | +```bash |
| 30 | +gofmt -w . |
| 31 | +``` |
| 32 | + |
| 33 | +## Project Structure |
| 34 | + |
| 35 | +- `main.go`: CLI entry point |
| 36 | +- `cmd/`: command implementation, request logic, bypass techniques, output, and tests |
| 37 | +- `payloads/`: payload lists used by techniques |
| 38 | +- `README.md`: user-facing usage and behavior documentation |
| 39 | + |
| 40 | +## Reporting Bugs |
| 41 | + |
| 42 | +Please use the bug report template and include: |
| 43 | + |
| 44 | +- NoMore403 version or commit SHA |
| 45 | +- operating system and architecture |
| 46 | +- Go version, if building from source |
| 47 | +- exact command and flags, with sensitive data redacted |
| 48 | +- expected behavior |
| 49 | +- actual behavior |
| 50 | +- minimal reproduction steps |
| 51 | +- relevant output, preferably with `-v` if it is safe to share |
| 52 | + |
| 53 | +For target-specific behavior, use a local reproduction or a public test target when possible. |
| 54 | + |
| 55 | +## Proposing Features or Techniques |
| 56 | + |
| 57 | +Before adding a new technique, check that it represents a distinct behavior and is not already covered by existing path, header, method, frontend, or raw HTTP logic. |
| 58 | + |
| 59 | +Good technique proposals usually include: |
| 60 | + |
| 61 | +- the parsing, normalization, or trust-boundary behavior being tested |
| 62 | +- why the result differs from existing techniques |
| 63 | +- an example request shape |
| 64 | +- expected signals in output |
| 65 | +- tests that verify the generated request shape, filtering, scoring, or replay behavior |
| 66 | + |
| 67 | +## Payload Changes |
| 68 | + |
| 69 | +Payload list changes should stay focused. Avoid adding very large lists unless there is a clear reason and the runtime impact is acceptable. |
| 70 | + |
| 71 | +When adding payloads, prefer entries that are: |
| 72 | + |
| 73 | +- reproducible |
| 74 | +- meaningfully different from existing entries |
| 75 | +- useful across common frontend, proxy, CDN, WAF, or application stacks |
| 76 | +- documented in the pull request when the behavior is not obvious |
| 77 | + |
| 78 | +## Pull Requests |
| 79 | + |
| 80 | +Pull requests should be scoped and easy to review. |
| 81 | + |
| 82 | +Before submitting: |
| 83 | + |
| 84 | +- run `gofmt -w .` |
| 85 | +- run `go test ./...` |
| 86 | +- run `go build ./...` |
| 87 | +- update documentation if behavior, flags, output, or payload expectations change |
| 88 | +- add or update tests for code behavior changes |
| 89 | + |
| 90 | +By contributing, you agree that your contribution will be licensed under the project's MIT License. |
0 commit comments