Developer · THE NO-PANIC PLAN
Inspect an SQL query for correctness and safety
SQL formatting can make structure easier to see, but it cannot detect every unsafe data flow or prove what a query will do. Identify the database engine and authorization context, trace untrusted values, review row-level effects and validate fixes with parameterized code against synthetic data.
MISSION Review a query?s dialect, data flow, permissions and effects without risking production records.
Open the database vendor documentation and OWASP SQL Injection Prevention guidanceTHE REAL-WORLD BIT
What happens outside this browser tab?
Establish engine and risk context; trace clauses and untrusted values; format only a redacted query; inspect permissions, row scope and dialect behavior; then correct the application code and add a safe regression test.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Name the database engine and review context
Identify the database product/version, SQL dialect, query purpose, caller permissions, whether input comes from a user, and the data sensitivity and transaction impact. Review a redacted query or synthetic fixture with schema details only as needed; do not paste customer rows, credentials or production connection strings into a public formatter. Confirm whether the query is intended to read, insert, update, delete, lock or change schema. Use a nonproduction or read-only environment and ask the database owner before testing anything that could expose or alter records.
- 02
Read the query as code and mark every trust boundary
Break the statement into clauses and trace each table, join, filter, sort, function, subquery and parameter to its source. Mark values derived from users, files, URLs or external systems as untrusted, and determine whether the application binds them as parameters or concatenates them into SQL text. Prepared statements separate SQL code from data and are OWASP?s primary recommendation. Placeholders bind values; they generally do not substitute table names, column names or sort keywords. For those structural choices, redesign the query or select from a small server-controlled allow-list instead of concatenating arbitrary input.
- 03
Format a redacted example for structural review
Nirmion?s SQL Formatter can indent a sanitized example so clauses and nested expressions are easier to scan. Remove literal personal values, tokens, customer identifiers, proprietary table names and comments that reveal internal data before using a general browser tool. Formatting only changes presentation; it does not prove the query is safe, syntactically valid for your engine, efficient or authorized. Compare the formatted statement with the engine-specific grammar and application code that supplies its parameters. If the query contains dynamic fragments, inspect how each fragment is selected and ensure user-controlled values are bound separately.
- 04
Check permissions, effects and dialect-specific behavior
For every statement, verify the selected columns and rows, joins, tenant or ownership filters, transaction boundaries, locking, limits and expected row count. Check whether a broad UPDATE or DELETE could affect more records than intended, whether NULL and type conversions change filters, and whether engine-specific functions or quoting rules are involved. Use the least-privileged account and a disposable fixture; inspect a query plan only in an authorized environment. Do not run an unknown statement in production, and do not infer that a read-only-looking SELECT cannot reveal sensitive data or create expensive load.
- 05
Correct the issue and preserve a safe regression case
Fix unsafe value handling with parameter binding in the application?s actual driver/ORM, and handle non-bindable identifiers with a fixed allow-list or a safer query design. Validate expected input types and permissions as defense in depth, not as a replacement for parameterization. Test the exact database dialect using synthetic data, including malicious-looking values as inert parameters, empty/boundary cases and expected row counts. Keep the redacted query fixture and an assertion about intended results in code review, then have the database/security owner approve production changes. A formatted statement or successful test alone is not a security audit.
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-06