DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.
Document domain manipulation arises when a script uses controllable data to set the document.domain property. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the response page to set an arbitrary document.domain value.
The document.domain property is used by browsers in their enforcement of the same origin policy. If two pages from different origins explicitly set the same document.domain value, then those two pages can interact in unrestricted ways. If an attacker can cause a page of a targeted application, and another page they control (either directly, or via an XSS-like vulnerability), to set the same document.domain value, then the attacker may be able to fully compromise the targeted application page via the page they already control, with the same possibilities for exploitation as regular cross-site scripting (XSS) vulnerabilities.
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. However, there are two important caveats to this. Firstly, browsers allow the use of child or parent domains, so an attacker may be able to switch the domain of the targeted application page to that of a related application with a weaker security posture. Secondly, some browser quirks enable switching to completely unrelated domains. These caveats mean that the ability to manipulate the document.domain property of a page generally represents a security vulnerability whose severity is not far behind regular XSS.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
The most effective way to avoid DOM-based document domain manipulation vulnerabilities is not to dynamically set the document.domain property using data that originated from any untrusted source. If it is necessary to programmatically set the document.domain property from within client-side code, then the application should employ a set list of acceptable values, and assign only from values in that list.