Get involved in the Burp challenge for opportunities to test your skills and win swag  –   Challenge me


General settings

  • Last updated: November 25, 2022

  • Read time: 5 Minutes

Testing for DOM-based vulnerabilities can often cause side-effects that prevent the website you're testing from working correctly. DOM Invader is highly configurable to ensure that you can fine-tune its behavior to achieve the best results.

To access the DOM Invader settings menu, click the Burp Suite logo in the upper-right corner of the browser, then switch to the DOM Invader tab.

General DOM Invader settings

The following general settings are available from the main DOM Invader settings menu.

Postmessage interception

When this setting is enabled, you can use the Messages view in the DevTools panel to test for DOM XSS in the site's web messages. For more information on DOM Invader's web message features, see Testing for DOM XSS using web messages.

There are also a few sub-settings that let you fine-tune this behavior. For more information, see Web message settings.

Message filtering by stack trace

Some websites trigger a large number of messages, which can make testing difficult due to the amount of noise. When this setting is enabled, DOM Invader compares the stack trace of each entry and hides any that point to the same location in the code as an existing entry.

Auto-fire events

When this setting is enabled, DOM Invader automatically triggers a click and mouseover event on every element as soon as the page loads. This is useful in cases where your injected payload only reaches a sink when one of these events occurs.

Redirection prevention

You may find that some of your actions cause a client-side redirect to another page. This can interfere with testing because the sources and sinks found by DOM Invader will be cleared and updated with sources and sinks found on the new page instead.

When this setting is enabled, DOM Invader blocks any client-side redirects so that you remain on the same page. However, redirects to javascript: URLs, or any redirects initiated by the Inject URL button, still work as normal.

Add breakpoint before redirect

Instead of blocking client-side redirects altogether using the Redirection prevention setting, you can enable this feature to set a breakpoint just before the code that triggers a redirect. Currently, this isn't possible using Chrome's standard DevTools.

Adding a breakpoint enables you to look at the call stack in the browser's DevTools to see where the redirect is happening, which can be useful for debugging.

Prototype pollution

When this setting is enabled, DOM Invader automatically tries to identify sources for client-side prototype pollution in addition to the usual DOM XSS sources and sinks.

For more information on DOM Invader's prototype pollution features, see Testing for client-side prototype pollution.

You can click the cog icon next to this setting to access some additional settings for fine-tuning this behavior. For more information on configuration options specific to prototype pollution, see Prototype pollution settings.

Inject canary into all sources

When this setting is enabled, DOM Invader automatically injects the canary in any identified sources on the page. It appends a unique string to the canary for each source so that you can easily identify which sources flow into each sink.

In practice, injecting the canary into every single source often prevents the site from working correctly. If you click the cog icon next to this setting, you can disable specific sources so that DOM Invader skips them. You might want to gradually eliminate problematic sources in order to use this feature more effectively.

You can also disable sources in order to focus on a specific one. This saves you having to manually paste the canary into the source every time you load a new page.

Changing the canary

At the bottom of the settings menu, you can see the canary string that DOM Invader is currently tracking. You can replace the randomly generated default canary at any time.

To change the canary:

  1. Enter the string that you want to use in place of the default canary.

  2. Click Update canary.

  3. Click Reload to refresh the browser. This is necessary for your changes to take effect. DOM Invader will now track the new canary string instead.


To avoid false positives, make sure that the string you use doesn't occur naturally on the page.

Customizing sources and sinks

To open the sources and sink settings, click the cog icon next to the main DOM Invader switch. From here, you can control which sources and sinks DOM Invader instruments. By default, all sources are hidden and only the most interesting sinks are instrumented.

Customizing sources and sinks

You might want to disable instrumentation of a particular sink if it is preventing the site from working correctly. For example, instrumenting eval() can change its behavior and break the related functionality.

Configuring callbacks

You can configure DOM Invader to execute custom callback functions whenever it identifies sources, sinks, or web messages. You can create your own custom callback or use the default, which enables you to export results by simply logging them to the console.

Configuring callbacks

Another useful callback might contain a debugger statement to pause script execution whenever DOM Invader identifies a controllable sink. This would enable you to study the call stack.

The default callback function is ready to use, but you need to enable it as follows:

  1. From the DOM Invader settings menu, click the cog icon next to the main DOM Invader switch to open the sources and sink settings.

  2. Select either the Sources, Sinks, or Messages tab, depending on which type of result you want to configure a callback for.

  3. Click the Callback configuration button to view DOM Invader's default callback function. Initially, this is deactivated.

  4. Click the text field containing the script to activate it.

  5. Either leave the script as it is, or make the changes you want, then click Save.

  6. Click Reload to refresh the browser. This is necessary for your changes to take effect.

  7. Use DOM Invader as normal and check that the callback works as expected.

Remove Permissions-Policy header

When this setting is enabled, DOM Invader automatically strips the Permissions-Policy header from responses when present.

Some websites set directives via the Permissions-Policy header that block features that are essential to DOM Invader's functionality, such as synchronous XHR. In this case, DOM Invader informs you via the console and prompts you to enable this option.

Was this article helpful?