I have a web app which displays what I enter in an <input> field back as HTML, but it happens all client-side in the DOM after manual input, so it can't be made into a URL which causes a payload to execute automatically.
For example, if you input <button onclick=alert(document.cookie)>a</button> it will alert the cookies back, but this can't be made into any exploit URL.
Would this be XSS? Why or why not?
If it is impossible to create a state of XSS that can be passed between machines - either as a request (doesn't have to be the URL, could be in a request body or even a cookie or header, though the last two are harder to exploit; could also be the URL fragment, which is easy) or as a server-side state (such that you could inject the malicious code and then point other people to the resulting page), then it's not exploitable for XSS. The "cross-site" part of XSS isn't always strictly necessary (e.g. if I can inject script into this answer, I could get XSS on everybody who open this question page even though that's the same site and indeed same page) but the ability for one person's actions to impact another person's view of the page is necessary, and that requires some form of state that can be passed between computers.
Mind you, the relevant state needn't pass through the server. For example, the server never even sees the URL fragment, but if the client contains script that processes the fragment (or any other potentially-attacker-controlled information, such as cookies or URL portions that the server received but ignored) then you can get DOM-based XSS. Similarly, the exploit needn't require any client-side script action (other than the payload), even if that's how the page is normally interacted with, if the server can be convinced to serve somebody the page with the malicious script already included (reflected or stored XSS).
