Supported Languages and Frameworks for Source Intelligence

NightVision Source Intelligence performs static analysis of API source code, leveraging common usage patterns of supported frameworks to generate OpenAPI documentation.

Customizations that extend or override framework routing behavior may prevent accurate OpenAPI generation. For best results, ensure that source code scanning includes all necessary libraries, submodules and plugins in addition to the root repository.

Supported languages and frameworks

Language	Web frameworks and routers
C#	ASP.NET Core MVC, minimal APIs, legacy ASP.NET MVC, and Web API 2
Go	net/http, gin, Echo, Fiber v2, chi, gorilla/mux, and httprouter
Java	Spring Boot/MVC/Data REST, JAX-RS/Jersey, and Micronaut
JavaScript/TypeScript	Express, Fastify, and NestJS
PHP	Laravel
Python	Django and Django REST Framework, Flask and Flask-RESTful, FastAPI, Starlette, and Connexion
Ruby	Ruby on Rails and Grape

Authentication and security schemes

Beyond routes, parameters, and responses, Source Intelligence reads the authentication and authorization guards on each endpoint and records them in the generated OpenAPI document:

• Detected guards become components.securitySchemes entries plus a per-operation security requirement. Recognized guards map to the standard OpenAPI scheme types: HTTP bearer (JWT), HTTP basic, HTTP digest, apiKey (in a header, query parameter, or cookie), and oauth2 / openIdConnect.
• Authorization role or scope names a guard requires are emitted on the operation as the x-roles extension. For oauth2 and openIdConnect schemes, where OpenAPI allows it, scopes are carried in the requirement’s scope list directly instead.
• When a route’s security posture is derived heuristically (for example from a hand-rolled middleware’s behavior, a naming convention, or an assumed framework default) rather than entirely from documented framework semantics, the operation is flagged with the x-unsound: ["security"] extension so consumers can treat it as an approximation. The same marker is applied when stacked guards are modeled as alternatives (OR) whose exact combination cannot be determined statically.

The per-language pages below list the specific frameworks, libraries, and guards recognized for each language.

Source and confidence extensions

Source Intelligence adds source and confidence metadata to the generated document:

• Every operation carries x-source: <file>~~<line>, the source file and line where the route was discovered. This is what links findings back to the exact source location.
• An operation the analyzer could not establish entirely from source may carry x-unsound. Its values identify the approximate part: path, method, handler, route, or security. Other parts of the operation can still be established from code. For example, x-unsound: ["handler"] means the registered path and method are known but the handler did not finish analyzing.

DAST sink hints

All seven language analyzers can add x-nv-dast-sinks to an operation when a modeled sink is statically reachable from its handler. The extension is a sorted, de-duplicated array and is omitted when no modeled sink was found.

paths:
  /reports/search:
    post:
      x-nv-dast-sinks:
        - redirect
        - sql-builder
        - sql-query
        - sql-read

The current tag vocabulary is:

Tag	Reachable handler behavior
sql-query	Issues a SQL statement. It accompanies the applicable SQL qualifiers below.
sql-read	Reads data with a SQL statement or ORM operation.
sql-write	Writes data with a SQL statement or ORM operation.
sql-raw	Uses SQL text supplied or assembled by the caller.
sql-builder	Uses a query builder, ORM, prepared statement, or another parameter-binding API.
os-command	Executes an operating-system command.
outbound-request	Makes a request to another server.
redirect	Redirects to a destination that is not fixed in source.
dynamic-code	Evaluates or dynamically selects code to run.
template-render	Renders a server-side template.
file-upload	Accepts an uploaded file.
llm-query	Sends a prompt to a language model. Currently emitted for modeled Python OpenAI, Anthropic, and LangChain calls.
llm-tool-call	Registers tools or functions for a modeled language-model call. It always appears with llm-query.

A tag reports reachable behavior, not a proven vulnerability or a complete data-flow result. For example, outbound-request does not by itself mean SSRF, and sql-query does not mean SQL injection. Missing tags mean that no modeled sink was found; they do not prove that the handler cannot perform that operation. NightVision treats this metadata as a prioritization hint and retains normal scan coverage when it is absent.

If a framework that you use is not listed, please contact our support team at support@nightviz.ai.