How to Detect SQL Injection in API Traffic

SQL injection (SQLi) has been around for decades, yet it keeps appearing in breach reports. The reason: APIs create new attack surfaces that traditional detection methods miss. Exploited vulnerabilities were the most common way in, at 31% of breaches, in the 2026 Data Breach Investigations Report.

Understanding where SQLi appears in API traffic, and how to detect it, is essential for any security team.

How do you detect SQL injection in API traffic?

Decode every input, then inspect each place an API accepts data: query and path parameters, JSON body fields and headers. Match SQL syntax by variant, confirm the context makes it real SQL, and correlate with the response and the source’s behaviour. Done on live traffic, this catches attacks your pre-production tests never saw.

Where SQL Injection Hides in APIs

Traditional web apps receive SQLi through form fields. APIs offer attackers more options.

Query parameters are the obvious target:

GET /api/products?category=electronics' OR '1'='1

Path parameters are often overlooked:

GET /api/users/1; DROP TABLE users--/profile

JSON body fields require parsing to inspect:

POST /api/search
{
  "query": "laptop",
  "filters": {
    "price": "100' UNION SELECT * FROM users--"
  }
}

HTTP headers sometimes feed database queries:

X-Tenant-ID: customer123'; DELETE FROM orders;--

WebSocket messages carry the same JSON into the same query builders, after the handshake where request-based filters stop reading. See WebSocket attacks that WAFs miss.

Common SQLi Patterns: The Five Variants Cyron Recognises

Detection systems look for patterns that indicate injection attempts. Patterns alone aren’t foolproof, because attackers use encoding and obfuscation, but they catch most automated attacks. Cyron recognises SQL injection in five variants. MITRE catalogues the weakness itself as CWE-89.

1. UNION-based. Appends a second query to read data from other tables:

' UNION SELECT username, password FROM users--
100' UNION SELECT * FROM users--

2. Boolean-based. Adds a condition that is always true, or tests true and false one question at a time:

' OR '1'='1
" OR "1"="1
' AND 1=1--

3. Comment-based. Cuts off the rest of the query, often to skip a password check:

admin'--
'; --
'/* comment */

4. Stacked queries. Ends the statement and starts a new one:

1; DROP TABLE users--
'; DELETE FROM orders;--

5. Time-based blind. Asks the database to wait, then measures the delay:

'; WAITFOR DELAY '0:0:5'--
' AND SLEEP(5)--
'; SELECT pg_sleep(5)--

Also watch for error-based extraction, where the attacker forces the database to leak data inside an error message:

' AND 1=CONVERT(int, @@version)--
' AND extractvalue(1, concat(0x7e, version()))--

Why Pattern Matching Isn’t Enough

Signature-based detection catches known patterns. Skilled attackers bypass it with encoding, case changes and comment insertion.

The same attack, three encodings:

%27%20OR%20%271%27%3D%271    (URL encoded)
' oR '1'='1                   (case variation)
'/**/OR/**/'1'='1             (comment bypass)

Effective detection combines pattern matching with behavioural analysis. Does this parameter normally contain SQL keywords? Is this user sending injection patterns across several endpoints? Has this address attempted similar attacks before?

Context checks are what keep alerts clean. A single quote in the surname O’Brien is not an attack. Nor is the word “select” in a product search. Before an injection match counts, Cyron checks that it would work as SQL where it appears: that a quote closes a string and what follows is a valid query fragment. Stray characters and ordinary words raise nothing, so the alerts your team sees are worth reading.

Detection in Practice

Modern API security analyses several signals:

Lexical analysis. Tokenising input to identify SQL syntax regardless of encoding. The string %27%20UNION becomes ' UNION before analysis.

Contextual checks. A single quote in a name field is normal. A quote that closes a string and is followed by UNION SELECT is not. Context matters.

Response correlation. Did the request trigger a database error? Did response time rise sharply? Did the response structure change unexpectedly?

Behavioural patterns. Is this source systematically testing endpoints? Are requests arriving faster than real users work?

A worked request

Here is one request, followed through each step.

GET /api/v1/orders?status=shipped%27%20UNION%20SELECT%20email%2C%20password_hash%20FROM%20users-- HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGciOi...

1. Decode. The query parameter becomes status=shipped' UNION SELECT email, password_hash FROM users--.
2. Locate. The value sits in status, a query parameter that normally carries one short word.
3. Match the variant. A quote closes the string, UNION SELECT adds a second query and -- comments out the rest: a UNION-based injection with a comment-based tail.
4. Check the context. The fragment is valid SQL in that position, so the match counts. The same quote in a customer’s surname would not.
5. Correlate. A response that suddenly grows, or returns fields this endpoint never sends, suggests the injection worked. The same source probing other endpoints marks a campaign, not a typo.
6. Act. An incident records the source, endpoint, location, variant and time, and goes to your SIEM. On a confirmed attack, a cryptographically signed command tells the agent on your host to block the source.

What Detection Outputs Look Like

Useful SQLi alerts include context beyond “injection detected”.

Essential fields: source address, targeted endpoint, injection location (query, body or header), the variant matched, a confidence level and a timestamp.

Advanced context: the user or session, related requests from the same source, and whether the injection appeared to succeed, based on the response.

Triage in three questions. When an SQLi alert arrives, ask three things before anything else:

• Did the response change? A larger body, new fields, a database error or a delay that matches the payload all suggest the injection reached the database.
• Is the source scanning? One payload against one endpoint may be a curious user. The same source walking through many endpoints and variants is an automated attack.
• What can the endpoint reach? An injectable search box on a read-only replica is serious. The same flaw on an endpoint that writes orders or reads customer records is urgent.

Answer those three, and you know whether to block the source, fix the endpoint today or both.

Steps to Take Today

1. Use parameterised queries everywhere, including handlers that read headers and WebSocket messages. The OWASP SQL Injection Prevention Cheat Sheet shows how for each major language.
2. Validate types at the edge: an ID that must be an integer should reject anything else.
3. Give your application’s database account the least privilege it needs, with no rights to drop tables.
4. Turn off verbose database errors in production.
5. Replay the variant examples above against staging, in every input location, and confirm each one is rejected and logged.
6. Watch live traffic for the five variants, so an attack on an endpoint nobody tested still raises an incident.

Detect SQL Injection Automatically

Cyron API Security detects SQL injection in five variants across query parameters, request bodies and headers, on live traffic and out of band: no added latency, nothing in your request path, no code changes. Get incidents with the full request context, delivered to your SIEM as signed, OCSF-aligned events.

Start free

Updated 1 October 2026: added a direct answer, the five SQL injection variants Cyron recognises, why context checks keep alerts clean, and one worked request.