zap ajax spider never finishes on javascript-heavy authorized app

Not specified by the original author.

TL;DR

The AJAX spider drives a real browser through clickable elements, and modern apps generate endless states: calendars, carousels, infinite scroll, and per-user routes. It never finishes because the state graph never ends. Bound it with a maximum crawl duration and depth, exclude the elements that generate states, and treat its output as a URL harvest to hand to the rest of the assessment.

zap ajax spider never finishes on javascript-heavy authorized app

Use this when

• An AJAX spider run against an authorized SPA has run far beyond its planned window with the URL count still climbing.
• The app has calendars, infinite lists, or generated routes that create new states forever.

Not for this skill when

• The crawl is slow but the state count is levelling off. Let a bounded crawl finish rather than restarting it.
• The app is mostly server-rendered pages. The traditional spider is faster and more predictable there.

Steps

1. Stop the current run and keep its discovered URLs; they are valid coverage even though the crawl did not formally finish. Verify: Verify: the sites tree retains the URLs found so far.
2. In the AJAX spider options, set a maximum duration and a maximum crawl depth that match the engagement timebox. Verify: Verify: both limits show the values you chose, not the defaults of effectively unbounded.
3. Add exclusions for state-generating elements and URL patterns, such as date pickers, next-page carousels, and sort or filter combinations, based on what the first run exploded on. Verify: Verify: the exclusion list names the patterns observed in the runaway crawl.
4. Reduce concurrent browsers if the tester box is struggling, since each AJAX spider browser is a full browser process. Verify: Verify: system memory stays stable during the rerun.
5. Rerun the bounded crawl and export the discovered URL list when the limit stops it, recording that coverage was timeboxed. Verify: Verify: the crawl ends by limit, and the exported list feeds the active scan plan.

Variant phrasings

zap ajax spider maximum duration depth settings

The settings phrasing.

ajax spider infinite scroll calendar endless states

The root-cause phrasing.

zap ajax spider out of memory many browsers

The resource phrasing.

Compatibility: Compatibility: OWASP ZAP 2.x AJAX spider with its bundled browsers; crawl state counts vary by add-on version.

Why it happens

The AJAX spider explores by interacting, and it stops when it runs out of new states. Reactive apps mint states combinatorially: every filter, page, and date multiplies routes, and client-side routing means there is no server 404 to prune the tree. Without explicit bounds the correct behaviour of the tool is, unfortunately, to crawl forever.

Edge cases / pitfalls

• Timeboxed coverage must be disclosed in the report; unexplored app states are a limitation, not a clean result.
• Some states only appear for particular roles; run bounded crawls per test role rather than one endless crawl.
• Watch for AJAX spider clicks that trigger real actions like sending mail or deleting items; exclude action elements on anything but a dedicated test tenant.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst11lBAX7uHHP6ptPWZbIcw

Resolved from the public thread: https://vectle.com/posts/pst11lBAX7uHHP6ptPWZbIcw

Thread query: zap ajax spider never finishes on javascript-heavy authorized app

TL;DR: The AJAX spider drives a real browser through clickable elements, and modern apps generate endless states: calendars, carousels, infinite scroll, and per-user routes. It never finishes because the state graph never ends. Bound it with a maximum crawl duration and depth, exclude the elements that generate states, and treat its output as a URL harvest to hand to the rest of the assessment.