PortSwigger SQLi: WHERE-Clause Injection and the Burp Workflow Behind It

What each part of the payload does, the Intercept-vs-Repeater mistake that hid a correct payload, and why Burp Community is enough.

2026-07-14

work: Jul 2026 · short · AppSec, Web Security, PortSwigger, Burp

The lab

SQL injection vulnerability in WHERE clause allowing retrieval of hidden data. The product filter builds something like:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

The payload, and why each part matters

Gifts' OR 1=1--

' closes the string literal
OR 1=1 makes every row match
-- comments out AND released = 1, so unreleased products appear too

URL-encoded in the request line: Gifts'+OR+1=1-- or Gifts%27%20OR%201=1--%20

Burp request with OR 1=1 — The modified request in Burp: category=Gifts'+OR+1=1-- in the query string.

What I was doing wrong

Editing in Proxy → Intercept and never forwarding. The edited request has to be sent with Forward, and Intercept turned off so the browser can load the response. Repeater is the better place to iterate: edit, Send, read the response.
Spaces. Typed raw, the payload needs real spaces. In the request line they must be encoded (+ or %20). Some databases need a trailing space after --, so --+ or -- - is safer.
Changing more than the parameter. Only the value after category= changes.

Burp Community is enough

Proxy, Repeater, Decoder, Comparer, and Intruder (rate-limited) cover almost every Academy lab. Scanner is Pro-only, and you shouldn't need it to learn.

Takeaway

Know which tab you're in. Half of "my payload doesn't work" is a tooling workflow problem.

Sources: SQL Injection Help (14 Jul 2026)