OWASP Noir: Source Code Endpoint Discovery for Security Testing

The endpoint visibility problem OWASP Noir addresses

OWASP Noir addresses the gap between routes that exist in source code and routes that appear during live crawling. Security teams often begin with an API inventory gathered through documentation, proxy logs, or a DAST crawler. That approach can miss deprecated handlers, internal routes, parameter variations, and undocumented endpoints. Noir instead reads the application source and builds an inventory of paths, HTTP methods, parameters, headers, cookies, source files, and tags.

The intended users are security engineers and code auditors who need a focused list of attacker-reachable entry points. The same inventory can be passed to LLM-based SAST agents, which reduces the amount of unrelated code an auditor has to inspect. Noir also targets DAST users. Instead of asking ZAP, Burp Suite, Caido, or Gori to discover every route by crawling a running application, a team can use the source-derived list as a target source.

This is endpoint discovery and context preparation, not proof of an exploitable vulnerability. Noir does not claim that every extracted route is deployed or externally reachable. Its value is narrower and more concrete: it makes the application surface declared by the code easier to review and test. Deprecated routes and shadow APIs appear in the same inventory as documented endpoints, so teams do not need a separate Noir mode to locate them.

Noir's static analysis and endpoint data flow

Noir's central mechanism is static analysis of source code. The README states that the analyzer supports 261 frameworks. For each discovered entry point, the resulting record can include the route path, request methods, parameters, required headers, cookies, source location, and tags. Those fields are more useful than a list of paths alone because a reviewer can inspect how a handler accepts input and locate the implementation that produced the result.

The workflow is source first, inventory second. A scan begins with a source directory, analyzers inspect framework routing constructs, and the extracted endpoints feed an output format selected for the next stage. The documentation also describes an LLM fallback for unsupported frameworks and custom routing when static rules do not apply. Noir can therefore combine deterministic analyzer results with model-assisted handling, but the README does not specify the prompts, provider configuration, credentials, or exact fallback behavior.

For AI-assisted review, `--include callee` adds one-hop functions invoked by each handler. The broader `--ai-context` option attaches aggregated guards, callees, sinks, validators, and signals to an endpoint. These features do not turn the tool into a vulnerability scanner by themselves. They package code relationships around each route so an LLM auditor can reason over a smaller and more relevant body of code.

Export targets for human review, CI, and DAST

Noir is designed around output handoffs rather than a single terminal report. The README lists JSON, YAML, OpenAPI, SARIF, cURL, Postman, and HTML. The practical choice depends on the consumer. JSON and YAML suit scripts or structured review systems. OpenAPI can be imported into DAST tooling. SARIF supports code-oriented CI reporting, while cURL and Postman formats can help a tester construct requests from discovered routes.

The DAST connection is the clearest extension of the source-derived approach. Noir can pipe a route list directly into ZAP, Burp Suite, Caido, or Gori as a proxy target. The documented alternative is to export OpenAPI and import it into a DAST tool. These methods differ from blind crawling because the scanner begins with routes found in code, including paths that a crawler might miss.

Noir also has a GitHub Action. According to the README, SARIF output and exit codes allow endpoint discovery to fit an existing CI pipeline. The repository includes `action.yml`, a `github-action/` directory, and a Dockerfile, confirming that automated and containerized delivery are part of the project layout. The README does not show the complete GitHub Action inputs or a full Docker invocation, so those settings should be taken from the project's current documentation rather than inferred.

Installing OWASP Noir and running a first source scan

The README does not provide platform-specific installation commands. It directs users to the official installation documentation at `https://owasp-noir.github.io/noir/get_started/installation/`, so there is no justified package-manager command, binary URL, or installation flag to reproduce here.

Once Noir is installed and available on `PATH`, this command opens its command-line help:

noir -h

The help output should expose the available CLI commands. Noir's May 2026 update introduced a verb-centric CLI structure, which is relevant when comparing older examples with the current interface.

The documented first scan accepts a source directory:

noir scan <source_dir>

Replace `<source_dir>` with the application's source tree. Noir should inspect that tree and print its endpoint inventory using its default presentation. The README does not document the default output format or every scan option in the displayed text, so readers who need a specific integration should consult the documentation for the corresponding flag.

For a first real workflow, scan a repository containing known documented and undocumented routes, then compare the result with the application's route definitions. Reviewing the source locations recorded for each endpoint is more useful than merely counting routes, because it shows whether the analyzer selected the intended handler.

Shadow API discovery versus live crawler discovery

Noir and a conventional DAST crawler use different primary evidence. Noir begins with source code and framework routing definitions. A crawler begins with an HTTP target and learns routes through links, responses, wordlists, proxy traffic, or other discovery techniques. This makes the approaches complementary rather than interchangeable.

A source-first process can identify a handler even when no navigation link reaches it, an authorization policy hides it, a gateway uses an unusual path, or a deployment no longer includes it. That is useful for deprecated-route and shadow-API inventories. A live crawler can also observe behavior that static analysis cannot establish, such as the HTTP status returned by a deployed service, redirects, runtime middleware, and differences between configured and deployed environments.

Noir should not be treated as a DAST replacement. Static extraction may include a handler that is disabled by deployment configuration, environment conditions, feature flags, or middleware. The README does not document runtime reachability validation, deployed environment discovery, or rollback procedures. A team seeking proof that a route responds on a particular host still needs requests, proxy data, or a DAST run.

The strongest use is often a two-source inventory: derive candidates with Noir, then send those candidates to a DAST tool and compare observed responses with the source-derived list.

Analysis limits for unsupported routing and dynamic paths

The largest limitation is framework coverage. Noir documents rules for 261 frameworks, but that count does not guarantee accurate recovery of every route in every application. Custom routers, generated route trees, metaprogramming, conditional registration, and framework-specific abstractions can obscure routes from static rules. The LLM fallback is intended for unsupported frameworks and one-off custom routing, yet the README does not provide an accuracy claim or configuration procedure for that path.

Dynamic path construction creates a related boundary. If a source file combines route fragments, configuration values, or runtime data in a way the analyzer cannot resolve, the emitted path may be incomplete or absent. The project layout includes analyzer, tagger, and test-related code, while the roadmap explicitly calls for broader framework coverage and honest accuracy based on per-framework fixtures. That roadmap language is more informative than a simple framework count because it acknowledges that coverage work is ongoing.

The `--ai-context` option also does not guarantee that an LLM will identify a vulnerability. It supplies guards, sinks, validators, callees, and signals around an endpoint. Human review is still required, especially when authentication, authorization, serialization, database access, or business rules cross more than the documented one-hop context.

OWASP Noir maintenance, upgrades, and MIT licensing

The repository is not archived, and the last push was on 2026-10-16. Recent releases include v1.4.0 on 2026-09-27, v1.3.1 on 2026-09-02, and v1.3.0 on 2026-08-18. The release history and recent repository activity indicate ongoing work on the 1.x line, although individual framework rules can still change as new route patterns are added.

The upgrade cost is higher than merely replacing a small standalone binary if a team also depends on output fields, SARIF integration, the GitHub Action, or generated route inventories. The README describes several analyzers, taggers, and passive-scan components, and the Dockerfile snapshots a separate passive-rules repository during the image build. Teams using the container should therefore review release notes and image behavior when changing versions rather than assuming an upgrade only changes the executable.

The project is licensed under MIT. That generally permits broad use, modification, distribution, and sublicensing subject to the license text and preservation of its conditions. Noir also has an OWASP project page and joined the OWASP Foundation in June 2024. Repository and project naming are not substitutes for reading the included `LICENSE` file when redistributing the software or embedding it in a product.

Editorial conclusion

OWASP Noir fits security engineers, code auditors, and teams that need a source-derived route inventory for LLM review or DAST scanning. It is less suitable for teams that require the analyzer itself to prove a route is reachable at runtime or for which the supported frameworks do not match their stack. Before adoption, verify coverage for the exact framework and routing patterns in the repository, then compare Noir's exported endpoints with routes already recorded by the application and gateway. The first project-specific acceptance check should be whether `noir scan <source_dir>` produces the expected shadow routes without unacceptable omissions.

Frequently asked questions

Official sources

1. License: MIT
2. owasp-noir/noir on GitHub
3. Project website
4. README
5. Releases