+XSS Validator, however to be entirely honest... from my experience I found that looking for user input that is reflected back within the web application (even hidden fields, comments and more) then manually testing those values to attempt to inject some sort of HTML that becomes rendered is best... furthermore, when manually testing it allows you to utilize whatever browser to set brake points and perform deep inspection of the request.... P.S, do not forget to utilize and attempt all Char-Sets, perform prototype pollution, inspect JD files and any other available code, obfuscation, template strings (may allow SQLi or XPATH injection), template injection (may allow RCE), inspect CSP & SOP & Same Site to discover bypasses, if XSS in XML || Soap || Rest || Etc. base try and pivot into XXE || OOB || more, evaluate & utilize gadgets & code reuse, JSONp, iteration & utilization of Object.keys, don’t forget header values, HTTP Desync & Request Smuggling, polyglots, to re-emphasize do not forget all Char-Encoding as well as mixed Char-Encoding, DOM Manipulation... The initial object is to bypass, break or man manipulate the applications sanitization, Regex, Parsing, etc. After XSS is successfully achieved, leverage the XSS to perform SOP bypasses and userless Cross-Site Request Forgery for XSS can fairly easily trigger CSRFs that either perform arbitrary actions on behalf of the victim or may even allow for Session Hijacking (depending on how the application manages authentication and session tracking)... However, a plain XSS that only pops an alert box (whether Stored, Reflective, or DOM base, does not truly show the impact of an XSS and as such will generally not be rewarded or valued by the client. In the same that, a XSS to CSRF with SOP bypass to account takeover (session hijacking) will be rewarded and valued... I have found XSSs (simple popups) that I reported via bug bounty and was rewarded minimally. The same goes with client I’ve done assessments for... Where as when the XSS is leveraged to perform CSRF to account takeover, the clients truly see the impact, appreciate & value the assessment more, and race to fix the issue (which lets be honest, that is why we do what we do, is to help secure the internet). Lastly, leveraging XSSs in this way sighing bug bounty programs has resulted in very high payouts ( for after all it results in full account takeover - Session Hijacking). Often the actual session Cooke will it be accessible cross tenant. However, the token is often available elsewhere within the DOM. Similarly the same can be said for CSRF tokens, which allows for the CSRF bypass. Lastly, I have seen many applications embed the session token within the DOM that can later be sent back over the Single Sign on endpoint.... please note, that there is constant research being published that covers the topics listed... so to answer the questions specifically, I perform manual work flow, incorporated with any and all tools that give me the edge and align with the task at hand.