Staaarter Tools

JSON to SQL Safety Checker

Recursively scans every string value in a JSON document for text patterns commonly associated with SQL injection attempts and reports which JSON paths were flagged and why, as a first-pass heuristic aid, not a replacement for parameterized queries. A free online tool from Staaarter, right in your browser.

Runs locallyUpdated 2026-07-26
securitylintingsql-injection

Overview

Introduction

SQL injection remains one of the most common and most damaging web application vulnerabilities, and it often shows up first as suspicious text sitting in an otherwise ordinary JSON payload: a form submission, an API request body, an exported log. This tool recursively scans every string value in a JSON document for text patterns commonly associated with SQL injection attempts, so you can quickly spot values worth a closer look.

It is a heuristic linter, not a SQL parser and not a security guarantee. It exists to speed up manual review of suspicious data, not to replace the real defense against SQL injection, which is parameterized queries.

What Is JSON to SQL Safety Checker?

A client-side scanner that walks a parsed JSON value recursively, at every level of nesting through objects and arrays, and tests every string value against a fixed list of case-insensitive patterns associated with SQL injection payloads: tautologies, comment markers, destructive statements, stacked queries, and a handful of other known techniques.

For every string that matches at least one pattern, it reports the JSON path to that value (in a $.user.name / $.items[2].note style), the value itself, and the specific reason(s) it was flagged, plus a total count of how many string values were scanned so you can confirm the scan actually ran over your data.

It runs entirely in your browser: nothing about your JSON, its content, or the fact that you scanned it, is sent anywhere.

How JSON to SQL Safety Checker Works

The tool parses your JSON, then walks the resulting value recursively: object values are visited under a dotted path (`$.key`, or `$["key with spaces"]` for keys that aren't simple identifiers), array elements under a bracketed index (`$.items[0]`), and every string encountered, regardless of depth, is tested against the full pattern list.

Each pattern is a regular expression written to be case-insensitive and reasonably broad. Multiple patterns can match the same string, in which case all matching reasons are reported together for that one finding rather than only the first match. Non-string values (numbers, booleans, null) aren't scanned, since SQL injection payloads are, by construction, text.

When To Use JSON to SQL Safety Checker

Use it when reviewing suspicious-looking data, an API request body a WAF or log flagged, a support ticket with a pasted payload, a set of test fixtures you're auditing before use, and want a fast first pass over which specific values and paths look worth investigating.

It's also useful as a teaching or code-review aid: pointing at a payload and immediately seeing which values match known injection patterns, and why, is a faster way to build intuition than reading about SQL injection in the abstract. It is not a substitute for a real SQL injection test (which would target your actual query construction) or for enforcing parameterized queries in your codebase.

Often used alongside LLM Output JSON Guardrail Validator, JSON Validator and JSON Value Extractor.

Features

Advantages

  • Recursively scans every string value at every nesting level, not just top-level fields, and reports the exact JSON path for each finding.
  • Reports the specific reason(s) a value was flagged, not just a pass/fail boolean, so you can judge each finding rather than trust an opaque score.
  • Runs entirely client-side; nothing about the payload you're reviewing is transmitted anywhere.
  • Fast enough to use as a first pass over any JSON payload before deeper manual or automated review.

Limitations

  • This is a heuristic pattern-matcher, not a SQL parser, and absolutely not a guarantee of safety. A clean result means no known pattern matched; it does not mean the data is safe to interpolate into SQL, and it cannot verify how your backend actually builds queries from this data.
  • Pattern matching produces both false positives (benign text that happens to contain a flagged fragment, like a comment mentioning "SELECT all that apply") and false negatives (a genuinely malicious payload cleverly obfuscated to avoid every pattern in the list). Every finding needs human judgment, not blind trust.
  • The only real, reliable defense against SQL injection is parameterized queries (prepared statements) or a parameterizing ORM/query builder. This tool cannot make unsafely-constructed SQL safe; it can only help you notice values worth a closer look before they reach a query.
  • The pattern list targets common, widely known injection techniques and SQL dialect keywords; it isn't exhaustive across every database engine's syntax and extensions, and it will miss patterns not in its list.

Examples

A tautology in a username field

Input

{"username":"admin' OR '1'='1"}

Output

{
  "success": true,
  "scannedStringCount": 1,
  "findings": [
    {
      "path": "$.username",
      "value": "admin' OR '1'='1",
      "reasons": ["Tautology condition (e.g. OR '1'='1') commonly used to bypass a WHERE clause check."]
    }
  ]
}

The value matches the tautology pattern, so it's reported with the JSON path $.username and the specific reason.

A destructive statement nested inside an array

Input

{"users":[{"note":"DROP TABLE users;"}]}

Output

$.users[0].note - "DROP TABLE users;" - DROP TABLE statement.

The path reflects both the array index and the nested key, even though the suspicious value is two levels deep.

Clean data produces zero findings

Input

{"name":"Ada Lovelace","age":30}

Output

{
  "success": true,
  "scannedStringCount": 1,
  "findings": []
}

No string value matches any pattern, but the count confirms the scanner actually examined the data (only "name" is a string; "age" is a number and isn't scanned).

Best Practices & Notes

Best Practices

  • Treat every finding as a prompt to investigate, not as a confirmed attack; read the actual value in context before acting on it.
  • Never rely on this tool, or any pattern-matching linter, as your actual SQL injection defense. Use parameterized queries or a parameterizing ORM for that, unconditionally.
  • Run it over data you're already suspicious of (flagged requests, support tickets, fixtures pulled from production) rather than treating a clean scan of arbitrary data as clearance.
  • When a genuine attack pattern is found in production data, treat it as an incident: check what happened to that data downstream, not just that this tool caught it.

Developer Notes

Patterns are matched independently per string value with `RegExp.test()`; a single string can accumulate multiple reasons if several patterns match. The pattern list includes: a generic OR/AND tautology check, `--` line comments, `/* */` block comments, `UNION [ALL] SELECT`, `DROP TABLE`/`DROP DATABASE`/`TRUNCATE TABLE`/`ALTER TABLE`/`DELETE FROM`/`INSERT INTO`/`UPDATE ... SET`, `EXEC(UTE)`, `xp_cmdshell`, `sp_executesql`, `WAITFOR DELAY`, `SLEEP()`, `BENCHMARK()`, a semicolon followed by another SQL statement (stacked queries), an embedded `SELECT ... FROM`, `CHAR()`-based obfuscation, and quote-breaking string concatenation. This list is deliberately broad (and therefore noisy) rather than narrowly tuned, on the theory that a security-adjacent linter should err toward over-flagging rather than silently missing something.

JSON to SQL Safety Checker Use Cases

  • Triaging a suspicious API request body or webhook payload flagged by a WAF, log alert, or support ticket.
  • Reviewing test fixtures or seed data before loading them into a shared or production-adjacent database.
  • Spot-checking user-generated JSON content (form submissions, imported records) during code review or an incident investigation.
  • Teaching or demonstrating what common SQL injection payloads look like in practice.

Common Mistakes

  • Treating a clean scan as proof of safety and skipping parameterized queries as a result; this tool cannot verify that, only pattern-match known text.
  • Ignoring findings because the flagged text "looks harmless" without actually reading the full value and its context.
  • Assuming the pattern list covers every SQL dialect and every obfuscation technique; it doesn't, and a determined attacker can craft payloads that avoid every listed pattern.
  • Running this tool on a database export as a stand-in for auditing how the application code that wrote that data actually builds its queries.

Tips

  • Pair this tool with the LLM Output JSON Guardrail Validator when the JSON came from an LLM: it's worth checking a model's structural output is even trustworthy before scanning its string content for SQL patterns.
  • If you're investigating a specific incident, search the findings for the exact reason category (tautology vs. destructive statement vs. stacked query) rather than only counting total findings, since the response varies by category.
  • Use the JSON Redactor first if the payload contains sensitive values you don't want visible while sharing a screenshot of the findings with a teammate.

References

Frequently Asked Questions