InQL: a Burp extension that turns a GraphQL schema into a test inventory

Three tabs, and the scanner is the one that matters

InQL is a Burp Suite extension, written in Kotlin, for testing GraphQL APIs. Its interface is organised into three primary components: the Scanner, the Batch Queries tab, and the Engine Fingerprinting tab.

The Scanner is the core. It takes a GraphQL endpoint or a local introspection schema file, then auto-generates all possible queries, mutations and subscriptions and lays them out in a structured view. That inversion is what makes the tool useful: instead of hand-writing requests to probe each field, you get the full surface of the schema enumerated and work through it.

The generated tree is also the input to the other two tabs. Engine Fingerprinting takes a GraphQL URL and retrieves information about the backend server technology, and Batch Queries runs batches of requests.

Because it is an extension rather than a standalone tool, everything it sees comes through Burp. There is no separate listener, no proxy configuration and no second application to learn.

Points of Interest turns the schema into a shortlist

A fully generated operation list is only useful if you can narrow it. The Points of Interest scan analyses the schema for potential vulnerabilities and returns a data set covering a variety of potential vulnerability categories. Those categories can be enabled or disabled according to what you are looking for.

Two details keep this from being pure noise. Scanning depth is configurable, so you can bound how far into nested types the generator walks, and the indentation width used in generated output is also adjustable, which matters because deeply nested GraphQL types are unreadable at the default.

Circular reference detection is separate and runs against the schema rather than as a category toggle. After analysing the schema, InQL displays potentially vulnerable queries in the scanner results view. InQL displays potentially vulnerable queries involving circular references so that they can be reviewed in the scanner results view.

Batch queries are framed as a rate-limit test

The Batch Queries tab is described as letting you run batch GraphQL attacks, useful for circumventing poorly implemented rate limits. The framing is blunt and accurate: the technique is to send many operations inside a single HTTP request so that per-request throttling never sees them individually.

That is a legitimate finding for a system you are authorised to test, since a rate limit that can be bypassed by batching is not a rate limit. It is also a capability you want scoped carefully, since the same tab produces request volume by design.

GraphQL servers process a batched array of operations in one round trip, so the security question is whether per-operation cost accounting survives batching. Where it does not, a single request can carry a limit's worth of expensive resolvers, and a scanner that shows you the resulting behaviour is the fastest way to establish whether the limit is real.

Introspection off does not mean blind, but the fallback is guesswork

The Schema Bruteforcer scanner is designed to recreate a schema when introspection is disabled. The README is specific about the method: it is based on the Clairvoyance CLI tool by Nikita Stupin, and it uses regex pattern matching to discover schema details.

That is the honest limitation of the whole tool, so it is worth stating plainly. When introspection is available, InQL works from a complete machine-readable schema and the generated coverage is exhaustive. When introspection is disabled, the scanner infers types from error responses and responses to guessed fields, and the quality of what it finds depends entirely on how verbose the server's errors are. A server returning a generic error for unknown fields will yield almost nothing.

If you are assessing a hardened endpoint, use the bruteforcer to enumerate what it can and treat the gaps as unresolved rather than as evidence that a field does not exist.

Burp integration is what removes the tooling overhead

The integration with Burp runs in both directions. You can generate queries directly from any GraphQL request already in Burp, and you can send auto-generated queries out to other Burp tools for further analysis. Burp's native message editors gain an additional GraphQL (InQL) tab for viewing and modifying GraphQL requests, with schema highlighting for readability.

Custom headers can be set per domain, and the domain list is auto-populated from observed traffic. That detail matters in practice: an endpoint that only answers when an authentication header or a tenant identifier is present will not enumerate without those headers, and having them inherited from traffic already passing through Burp removes a whole class of setup friction.

There are also built-in GraphiQL and GraphQL Voyager servers. You can send the analysed schema into them and explore it interactively, which is a faster way to understand a large schema than reading the generated operation list top to bottom.

The hard requirements are Burp's newest release and Java 17

Installation requirements are short and strict. Support is only provided for the most recent version of Burp, and it is compatible with both the Professional and the Community editions. For Java, the requirement is stated in terms of the API rather than the runtime: the Montoya API needs Java 17 or later.

The Burp restriction is the one that will decide things for a team. Pinning to the newest Burp release means your extension updates in lockstep with the proxy, and there is no supported fallback if an upgrade breaks the extension. InQL supports both the Professional and Community editions.

The repository is a Gradle project with build.gradle, settings.gradle, gradlew and gradlew.bat alongside a Taskfile.yaml and detekt.sh, and it ships a BappManifest.bmf plus BappDescription.html, which are the files the BApp Store uses. Building from git starts by installing Java 17 or later, and the README shows the Debian package command as the example.

Version 6.1.2 is the tag, and the master branch has moved since

InQL is Apache-2.0 licensed and hosted under the Doyensec organisation, with the vendor homepage at doyensec.com. The release history is v6.0.0 on 2025-04-08, v6.1.1 on 2025-12-01 and v6.1.2 on 2026-02-16, and the README title itself names the version as InQL v6.1.2.

The repository itself is more current than that. The last push was on 2026-10-13, eight months after the v6.1.2 tag, and the README carries a badge comparing the dev branch against master, which indicates a dev branch that runs ahead. If you want what is on master rather than what is in the last release, expect a different build from the one the README describes.

Given the requirement to support only the newest Burp, the release cadence is the thing to watch rather than the licence. The Apache-2.0 terms mean you can install the extension into a commercial engagement without licence friction, and the code of conduct, pre-commit configuration and detekt script show a project with process, not just a binary.

Editorial conclusion

Adopt InQL if you already work in Burp Suite and are assessing GraphQL endpoints you are authorised to test, since it needs no separate proxy or scripting environment and reads queries straight out of Burp traffic. Do not adopt it if your team does not use Burp, or if you need support for an older Burp release, since only the most recent version is supported. Verify first whether the target exposes introspection: if it does not, the schema bruteforcer falls back to regex pattern matching based on the Clairvoyance tool, and its coverage of an unusual schema is not something the README quantifies.

Frequently asked questions

Official sources

1. doyensec/inql on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases