NoirAIContext::Builder

Capture 1 is the bare-key noun, capture 3 the quoted-key noun; exactly one of them is set per match.

Sensitive-response detection runs as a two-step check on the route-scope snippet:

1. RESPONSE_EMITTER_PATTERN — the snippet serializes a response, either through a helper (res.json, jsonify, render json:, to_json, …) or by returning a literal (return {...}).
2. CREDENTIAL_KEY_IN_RESPONSE — the snippet also has a credential noun as a key, in either of the two spellings a response literal uses: bare — { token: … } (JS/TS shorthand, Ruby, YAML) quoted — { "token": … } (JSON, Python dicts, Go maps, PHP arrays, any serialized body)

Both have to match in the same scope. The earlier single-regex version was too loose and caught english prose mentioning credentials in response strings, so the fix required the noun not be preceded by a quote. That over-corrected: it also excluded every quoted key, which is the dominant shape in most languages, and the signal quietly stopped firing on them.

The two branches below keep the original guard for bare keys while admitting quoted ones, and stay narrow because the quoted branch requires the string to close immediately after the noun. { message: "Set X-API-KEY header" } still doesn't fire — the noun sits mid-string, so no closing quote follows it.

Some analyzers (express's loose destructuring, Java route extractors that don't follow @RequestBody Credentials c.password, …) miss credential-bearing parameters at extract time. When that happens the param-based credential_input signal never fires and downstream heuristics like rate_limit_absence silently skip the route.

As a backstop, scan the route-scope snippet for the canonical request-body destructuring shapes (req.body.password, request.form['password'], { password } = req.body, …) and emit a credential_input signal with a slightly lower confidence than the param-based one. The kind is the same so downstream rate_limit_absence / guard_absence logic catches it transparently.

Resolved once from the catalog instead of re-scanning PARAM_PATTERNS on every call. identifier_like? in particular runs several times per parameter per endpoint, and the answer never changes.

Log injection / sensitive data in logs. Catches the canonical "log user input or credential field directly" shape. False positives are bounded because both the log call AND a user- input reference (or credential noun) need to be on the same line / snippet window.

Suppression for unsafe_method: route handlers that branch on request.method (Flask / Django) or req.method (Express, Node, Go's r.Method, Java's request.getMethod()) typically register a single route under multiple methods. Analyzers split that into one endpoint per method but share the callees list. The mutating callee in the GET endpoint is often the POST branch's call, not actually reachable via GET.

Each verb may be followed by additional word chars (destroy_all, createMany, deleteOne, updateUser), so we don't anchor with a trailing \b — that would miss those suffixed forms because _ and word continuation count as the same word in regex.

A mutating verb anywhere in the callee name (start, after a separator, or as a CamelCase segment) disqualifies the endpoint from "read-only POST". Without this, a callee like getOrCreate/findAndDelete matches the read-only pattern via its leading read verb, silently suppressing the state-change review signal on an endpoint that does mutate.

Categories whose mere presence is a security-review signal — used alongside concrete signals to compute the overall priority bucket.

The emitter list was built from helper calls (jsonify, res.json, …) and so missed the frameworks that serialize a returned literal with no helper at all: FastAPI and modern Flask handlers just return {...}, which is the single most common response shape in the Python corpus. Without it the credential-key check could not run on those handlers no matter what the payload held.

Concrete review-worthy signal kinds. These are the "this is actually scary" categories — not the structural ones (route_definition, technology, path_param) that every endpoint surfaces.

HTTP method intent vs implementation mismatch. A GET/HEAD endpoint that mutates server state through a callee (User.create, record.destroy, db.delete, …) is a textbook CSRF / side-effect-on-read bug — the verb says "safe / idempotent" but the code says otherwise. QUERY makes the same promise (RFC 10008 defines it safe + idempotent), so a mutating QUERY handler earns the same signal. The shared set keeps this file, the taggers, and the probe path-filler agreeing on what a read is.

This check needs the response emitter and the credential key in the same window, and in real handlers they sit far apart — the body assembles a dict/struct first and serializes it at the end. Under the default 12-line / 240-char route scope the two could not co-occur, so the signal never fired on the shape it exists to catch. Widen the window for this check only; the scope walk still stops at the end of the handler, so it cannot pair one route's emitter with another route's payload.