location.searchproperty because it reads input from the query string, which is relatively simple for an attacker to control. Ultimately, any property that can be controlled by the attacker is a potential source. This includes the referring URL (exposed by the
document.referrerstring), the user's cookies (exposed by the
document.cookiestring), and web messages.
Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session.
IndexedDB (mozIndexedDB, webkitIndexedDB, msIndexedDB)
innerHTMLsink doesn't accept
scriptelements on any modern browser, nor will
svg onloadevents fire. This means you will need to use alternative elements like
This kind of XSS is probably the hardest to find, as you need to look inside the JS code, see if it's using any object whose value you control, and in that case, see if there is any way to abuse it to execute arbitrary JS.
DOM-based open-redirection vulnerabilities arise when a script writes attacker-controllable data into a sink that can trigger cross-domain navigation.
Remember that if you can start the URL were the victim is going to be redirected, you could execute arbitrary code like:
DOM-based cookie-manipulation vulnerabilities arise when a script writes attacker-controllable data into the value of a cookie. This could be abuse to make the page behaves on unexpected manner (if the cookie is used in the web) or to perform a session fixation attack (if the cookie is used to track the user's session).
Document-domain manipulation vulnerabilities arise when a script uses attacker-controllable data to set the
document.domainproperty is used by browsers in their enforcement of the same origin policy. If two pages from different origins explicitly set the same
document.domainvalue, then those two pages can interact in unrestricted ways. Browsers generally enforce some restrictions on the values that can be assigned to
document.domain, and may prevent the use of completely different values than the actual origin of the page. But this doesn't occur always and they usually allow to use child or parent domains.
WebSocket-URL poisoning occurs when a script uses controllable data as the target URL of a WebSocket connection.
WebSocketconstructor can lead to WebSocket-URL poisoning vulnerabilities.
DOM-based link-manipulation vulnerabilities arise when a script writes attacker-controllable data to a navigation target within the current page, such as a clickable link or the submission URL of a form.
Ajax request manipulation vulnerabilities arise when a script writes attacker-controllable data into the an Ajax request that is issued using an
Local file-path manipulation vulnerabilities arise when a script passes attacker-controllable data to a file-handling API as the
filenameparameter. An attacker may be able to use this vulnerability to construct a URL that, if visited by another user, will cause the user's browser to open/write an arbitrary local file.
Client-side SQL-injection vulnerabilities arise when a script incorporates attacker-controllable data into a client-side SQL query in an unsafe way.
HTML5-storage manipulation vulnerabilities arise when a script stores attacker-controllable data in the HTML5 storage of the web browser (either
DOM-based XPath-injection vulnerabilities arise when a script incorporates attacker-controllable data into an XPath query.
DOM-based JSON-injection vulnerabilities arise when a script incorporates attacker-controllable data into a string that is parsed as a JSON data structure and then processed by the application.
Web-message vulnerabilities arise when a script sends attacker-controllable data as a web message to another document within the browser. Example of vulnerable Web-message manipulation in https://portswigger.net/web-security/dom-based/controlling-the-web-message-source
postMessage()method for sending web messages can lead to vulnerabilities if the event listener for receiving messages handles the incoming data in an unsafe way.
DOM-data manipulation vulnerabilities arise when a script writes attacker-controllable data to a field within the DOM that is used within the visible UI or client-side logic. An attacker may be able to use this vulnerability to construct a URL that, if visited by another user, will modify the appearance or behaviour of the client-side UI.
DOM-based denial-of-service vulnerabilities arise when a script passes attacker-controllable data in an unsafe way to a problematic platform API, such as an API whose invocation can cause the user's computer to consume excessive amounts of CPU or disk space. This may result in side effects if the browser restricts the functionality of the website, for example, by rejecting attempts to store data in
localStorageor killing busy scripts.