Tools · Web testing tools · 14 / 23
ZAP’s Sites tree and History table
The Sites tree is ZAP’s map of hosts and paths. History is the time-ordered table of every message the proxy or the spider recorded. You use the tree to see the shape of Harbor Ledger and the table to read one exchange.
The Sites tree is the map
The Sites tab builds a tree as the proxy and the spider see URLs. For this lab the only host node you want is http://127.0.0.1:3000. Under it, the paths should look like the map you already wrote in Burp if you did that pass: pages, API, health, and static files. Differences are interesting. A path ZAP has and Burp did not is a link you did not click. A path Burp has and ZAP does not is a link the spider could not see, often because it never had Avery’s session.
Click a node and read the messages attached to it. The tree is not a score. A thick tree means more URLs were fetched. It does not mean the app is in worse shape.
History is the log
History lists messages in time order, with method, URL, status, size, and the source (proxy or spider). This is the table you use to check an alert. It is also the table you use to see whether the spider spent its time on /static/app.js variants or actually reached /api/invoices.
The filter bar accepts a URL regular expression. Anchor it to the lab so a sloppy expression does not keep a second host on screen. The expression below is the API only. Clear it when you want the HTML pages back.
URL regex: ^http://127\.0\.0\.1:3000/api/.* Rows you expect after a signed-in browse or a spider that held a session: GET /api/invoices GET /api/invoices/1042 GET /api/invoices/1048
Request and response under the table
Select a row and use the panes below the table. Read the request line and the Cookie header long enough to know a session is present, without copying the value. Read the response status and Content-Type. For a JSON row, find owner. The Pretty view is the reading aid. The Raw view is what you quote.
If you cannot find a row the alert named, the filter is hiding it, or the alert is stale from an earlier session. Clear the filter and search the URL. An alert whose message is gone is an alert you cannot confirm. Say that in the note, and do not invent a confirmation from the rule name.
Worked case: does the tree match the routes you know?
With Harbor Ledger running and ZAP proxying the lab browser, sign in as Avery and open the list and both invoices. Look at the Sites tree and write the path list. Then look at History with the API filter and write the statuses. Compare the two lists to the routes you believe the app implements. Any route you know about that is missing from both was not linked and was not typed. That is a coverage fact, not a flaw by itself.
If the tree grows a second host, stop the exercise and fix the page. The rest of the ZAP lessons assume a tree with one host. A tree with two hosts means the context lesson has nothing clean to include.
Diagram
Map first, then one message
- Sites
Under http://127.0.0.1:3000 the tree lists the paths the proxy or the spider has seen.
- History
The table lists those fetches in order, including repeats.
- Filter
A filter on the lab origin and the /api/ prefix leaves the JSON calls.
- Message
The lower panes show the request and the response for the selected row.
Tree or table
Question. You want to know what a single click did.
Tool. You only look at the Sites tree.
Miss. The tree shows one node per path, so a repeated call disappears.
Question. You want the order of one click.
Tool. History, filtered to the lab, read from top to bottom.
Keep. The Sites tree stays open so you can see whether the path is new.
Method: any URL regex: ^http://127\.0\.0\.1:3000/api/.* Show only in-scope messages: on
Check yourself
1. The Sites tree shows one node for /api/invoices/1042. History shows that URL three times. What is going on?
2. Which filter leaves Harbor Ledger’s JSON calls?
3. A second host appears in the Sites tree during the baseline. What do you do with it?