How Chrome DevTools helps to defend against self-XSS attacks

Wolfgang Beyer
Wolfgang Beyer
X GitHub

What are self-XSS attacks?

Self-XSS, or self cross-site scripting, is a type of social engineering attack that tricks you into executing malicious code in your web browser. Unlike regular XSS attacks, which rely on vulnerabilities in web applications that let attackers inject malicious code, self-XSS attacks rely on your own potential code execution actions.

Self-XSS attacks typically involve the attacker tricking you into copying and pasting malicious code into your browser's DevTools Console. The attacker usually achieves this by promising some kind of reward. This may be:

  • Promising you that the code will give you access to hidden features or virtual rewards.
  • Pretending that the code is a security test or bug fix.
  • Promising that the code allows hacking into a website for your gain.

Once you execute the code, the attacker can then gain control of your account. This can allow the attacker to:

  • Steal your personal information, such as name, address, and credit card number.
  • Post unauthorized messages or comments on your behalf.
  • Take control of your social media accounts.
  • Spread malware to other users.

How does Chrome DevTools try to mitigate self-XSS attacks?

Letting users paste code into DevTools and then execute it is inherently risky. But it's also one of the core features of Chrome DevTools. So we had to find a balance between mitigating potential self-XSS attacks and not interfering with the work of developers who just want to debug websites.

Developers don't usually copy code they find somewhere on the web, paste it into DevTools, and execute it, without first taking a quick look at what the code does. Most developers are very much aware of the security risks of executing code that they found in a sketchy corner of the web.

Chrome DevTools trusts developers to know what they're doing. We don't want to slow them down or distract them in any way when they are copying and pasting code.

We think that non-developers are at a much higher risk of falling victim to a self-XSS attack. In order to protect you, we believe it's acceptable and beneficial to interrupt when you are doing something potentially dangerous. When Chrome DevTools detects that an inexperienced user is trying to paste code into DevTools, it'll stop and show a warning.

When will DevTools show self-XSS warnings?

DevTools uses a very simple heuristic to decide whether to show self-XSS warnings: it is based on the console history of your user profile.

If your profile has at least 5 entries in its console history, DevTools won't bother you with any warnings or pop-ups. The console history is the list of commands you've typed and executed in the Console. These are the commands you see when you place the cursor in the Console and press the up arrow key repeatedly.

What do the self-XSS warnings look like?

When an inexperienced user tries to paste code into the Console, this action is blocked and the Console shows a warning instead.

The self-XSS warning in the Console.

You can override this warning and enable pasting, but you need to type 'allow pasting' to do so.

When an inexperienced user pastes code into the DevTools code editor (for example, the Sources panel), the user experience is very similar. Instead of a warning, you will see a modal dialog.

The self-XSS modal dialog in the Sources panel.

And again, closing this dialog alone is not enough to enable pasting. To override the warning, you need to type 'allow pasting' into the input field.

Is that a one-time setting?

Yes, once you decide to allow pasting, you won't be bothered with self-XSS warnings ever again.

We hope that this achieves a good trade-off between usefulness and annoyance. By adding friction, we increase the likelihood of you reading the warning and therefore decrease the likelihood of a successful self-XSS attack.

Chrome DevTools keeps a flag that specifies whether or not to show you self-XSS warnings in your Chrome profile. So if you create a new profile and immediately start pasting code into DevTools, pasting is blocked and self-XSS warnings are shown instead.

Can you disable it for test automation?

But what about automated tests? Many testing tools create a fresh temporary profile for every test run. So if you use DevTools to debug your automated tests, pasting into the Console is initially blocked.

To circumvent this issue, do either of the following:

  • Use Chrome for Testing, a variety of Chrome designed specifically for testing and automation. Self-XSS warnings are turned off.

  • For other Chrome release channels, pass the --unsafely-disable-devtools-self-xss-warnings command-line flag to Chrome to disable the self-xss warning dialog entirely.

Conclusion

What do you think of this strategy for mitigating self-XSS attacks? If you have comments or suggestions, add a comment to this bug or reach out using one of the following methods.

Especially if you are working on a website that warns about self-XSS attacks through console logs, we'd love to talk about aligning our efforts or measuring the impact of self-XSS mitigation measures.

Download the preview channels

Consider using the Chrome Canary, Dev, or Beta as your default development browser. These preview channels give you access to the latest DevTools features, let you test cutting-edge web platform APIs, and help you find issues on your site before your users do!

Get in touch with the Chrome DevTools team

Use the following options to discuss the new features, updates, or anything else related to DevTools.