Published: March 17, 2025
Last year, we announced improved security for cookies and credentials with App-Bound Encryption for Chrome.
While we observed that this new protection resulted in a substantial reduction in this type of account hijacking, attackers remain very motivated to adapt to these new defenses and we continue to monitor the techniques and behaviors used by infostealers.
Since App-Bound Encryption was enabled we've seen an increase in attackers using Chrome Remote Debugging to extract cookies. Using this method to steal Chrome cookies has been discussed since 2018. However, recent blog posts covering this use of the remote debugging port, and tools to extract cookies support our internal data showing its increased popularity. We remain committed to disrupting these techniques, and constraining attackers further—increasing the cost of these attacks and protecting the security of Chrome users.
Therefore, from Chrome 136 we're making changes to the behavior of
--remote-debugging-port and --remote-debugging-pipe. These switches
will no longer be respected if attempting to debug the default Chrome data
directory. These switches must now be accompanied by the --user-data-dir
switch to point to a non-standard directory. A non-standard data directory uses
a different encryption key meaning Chrome's data is now protected from
attackers.
For developers who need to debug Chrome (for example, from VSCode), the instructions already specify use of a custom user data dir and we continue to recommend this approach to isolate any debugging from any real profiles.
For browser automation scenarios, we recommend using Chrome for Testing which will continue to respect the existing behavior.
Please file any issues with this new security feature to crbug.com.