The useful version of automated scanning is not “scan everything and wait.” It is “I think this boundary matters, so test this boundary hard.”

The PortSwigger Essential Skills labs make that distinction explicit. They are not really about new bug classes. They are about using Burp Scanner as a focused instrument during manual testing.

The human chooses the boundary

In the file-read lab, the time limit changes the workflow. A full-site scan may eventually find the issue, but it burns time on low-value requests.

The better sequence is simple:

• inspect normal traffic;
• find the request most likely to read a server-side resource;
• run a targeted scan on that request;
• take the scanner’s vector back to Repeater;
• reduce it to a proof that reads /etc/passwd.

The scanner accelerates the middle of the process. It does not decide what matters.

Hidden inputs are still inputs

The non-standard data-structure lab is the more important lesson. The authenticated cookie contains a visible structure:

username:session-id

That is not one opaque value. It is two parsed fields sharing one cookie. Selecting only the username portion as an insertion point lets Scanner test the field the application actually trusts.

Once the stored XSS finding appears, the final proof preserves the session-id half and changes only the username half. Without that preservation, the request loses its authentication state.

Scanner output needs interpretation

Scanner findings are not the end of testing. They are leads:

• What exact parser accepted the input?
• Which sub-field became trusted data?
• Which output context rendered it?
• What is the smallest proof?
• What server-side invariant failed?

Those questions turn a scanner result into an engineering fix.

Defender notes

Hardening:

• keep session cookies opaque and random;
• avoid packing user-controlled fields into authentication cookies;
• sign and schema-check structured values when structure is unavoidable;
• treat file access as resource lookup, not path concatenation;
• canonicalize paths before enforcing directory containment;
• encode stored content for the exact browser context.

Detection:

• traversal strings or absolute paths in resource parameters;
• HTML/event-handler payloads in cookie sub-fields;
• one insertion point receiving many scanner payload variants;
• privileged browser sessions causing unexpected outbound DNS or HTTP callbacks.

Targeted scanning works because it keeps automation attached to a manual model of the application. The model is the work; the scanner is the amplifier.