Tools · Web testing tools · 11 / 23
The inspector and a note someone else can check
The inspector breaks one message into method, path, headers, cookies, and body fields so you can read it without losing your place in the raw text. The note you keep is a short form filled from that breakdown, not a paste of the whole message.
Raw text and a list of attributes
Select the history row for GET /api/invoices/1042. The message editor shows the request as text. The inspector, in current Burp, is the side pane that parses that text into attributes: method, path, HTTP version, a row per header, a row per cookie, and query or body parameters when they exist. The response side does the same for status, response headers, and body fields when the content type is something the inspector understands.
Read the attribute list once from top to bottom. You are looking for a second cookie, a host that is not 127.0.0.1, or a body field the pretty view scrolled past. The list and the raw text are the same message. If they disagree, believe the raw text and treat the disagreement as a parsing quirk worth a sentence in the note.
Pretty-print is a reading aid
JSON in a single line is hard to read and easy to quote incorrectly. The pretty view breaks it into lines so owner and status are visible. Use it to find the field. When you copy the value into the note, glance at the raw view and copy from there if you are claiming the exact characters. Whitespace in the pretty view is for your eyes.
The same split applies to the request. A form body shown as name and value pairs is the inspector doing you a favor. The raw body is what the app parsed. For the note save, those should match: one field, the note you typed. If the inspector shows a field you did not type, that is the thing to write down.
The note form
Keep a text file in the lab folder, not inside the Burp project. Each interesting exchange gets the same lines: host, account, where you were in the tool, request line, status, content type, the fields you checked, whether the URL was in scope, and a reminder that the cookie was not copied. Sameness is the point. A reader can compare two notes, and you can see the blank line where you forgot to look.
“Where” is the line people skip and the line that saves time. “Proxy history” and “Repeater tab GET invoice 1042, send 2” are different places. A reviewer who opens the project, or who repeats the browse, needs that pointer. Organizer, on editions that include it, can hold the same form next to the message. A text file works on every edition and survives after the temporary project is gone.
Host: 127.0.0.1:3000 Account: Avery (seed) Where: Proxy history Request: GET /api/invoices/1042 Status: 200 Content-Type: application/json Checked: owner = avery@ledger.lab In scope: yes Cookie value: not copied
Worked case: one note for the baseline invoice
After the mapping pass, fill the form for invoice 1042 from the inspector, not from memory of the seed data. Then fill it again for invoice 1048. Put the two notes one after another in the text file. Read them aloud. A person who was not at the keyboard should be able to say which fields match and which fields differ, which is the same answer Comparer gave you, now in a form you can keep after Burp closes.
If a line tempts you to paste the cookie “just for the lab group chat,” delete the temptation by leaving that line as the words “not copied.” The group can sign in with the seed account and open the same path. They do not need your session to check your sentence.
Diagram
From a raw message to a five-line note
- Raw
The message editor shows the bytes as they will be sent, or as they came back.
- Inspector
The side pane lists the same bytes as attributes: method, path, one header per row, one cookie per row, body fields.
- Pretty
JSON pretty-print is for reading. Raw is what you quote if a single character matters.
- Note
Five lines: host, request, account, status, and the field you checked. The cookie value stays out.
What leaves the project file
Contents. Request line, every header, the Cookie value, the whole body.
Reader. Has a live lab session, whether they needed it or not.
Check. Hard to see which field the writer meant.
Contents. Host, method and path, account name, status, owner field.
Reader. Can reload the page as Avery and look at the same field.
Check. The sentence is true or false against one response.
Host: 127.0.0.1:3000
Account: Avery (seed)
Where: Proxy history, then Repeater tab “GET invoice 1042”
Request: GET /api/invoices/1042
Status: 200
Content-Type: application/json
Checked: owner = avery@ledger.lab
invoice status = open
In scope: yes
Cookie value: left in the project, not copied hereCheck yourself
1. What is the inspector for, on a Harbor Ledger response?
2. You want the note to be checkable, and you do not want to hand out Avery’s session. Which lines do you keep?
3. Pretty-print shows the owner clearly. When do you switch back to raw?