> ## Content Index > Fetch the complete content index at: https://securinglaravel.com/llms.txt > Use this file to discover other available public pages before exploring further. # Security Tip: Intercepting dump() Could Expose Production! - URL: https://securinglaravel.com/security-tip-intercepting-dump-could-expose-production/ - Published: 2024-08-18T10:51:35.000Z - Updated: 2024-08-18T10:51:35.000Z - Description: [Tip #89] dump() interceptors in dev tools like Herd and Telescope are very helpful, but be careful you don't accidently send dump() to production! - Author: Stephen Rees-Carter - Tags: Security Tips, Debug, Dev Tools, Leaking Data Laravel [Herd Pro](https://herd.laravel.com/?ref=securinglaravel.com) and [Telescope](https://laravel.com/docs/telescope?ref=securinglaravel.com) are incredibly useful dev and debugging tools, with a variety of features. One of their more useful features is the *Dump Watcher*, which allows you to inject `dump(...)` anywhere in your code and then see the output within their own dump viewer - rather than on the page or in the terminal. 💡 The **Dump Watcher* can be incredibly useful when you're debugging complex code or interfaces, where having `dump()`'s output displayed will break the page or cause other issues. There is, however, one significant downside to using this feature: the output of `dump()` is no longer immediately visible on the page when you're working on it. This means you may forget you're dumping output, leave the `dump()` within your code, and then commit and deploy to production. **The end result: `dump()` ends up on production, potentially exposing sensitive data! 😱** 🤓 **Before I get comments pointing out that Herd's Dump watcher pops up when it picks up a new dump - it's still a separate window. It's easy to lose track of different windows when you're buried deep in a problem. (Or at least, it's easy for me to lose track, so maybe this one is just for my benefit?)* 🤷 Even ignoring the use of these *Dump Watchers*, it's fairly common to hear of situations where `dump()` and even `dd()` have made it onto production and leaked data. So this feels like something we need to address. **To avoid this potential issue, here are my recommendations:** 1. If you use Pest for testing, set up an [architecture test](https://pestphp.com/docs/arch-testing?ref=securinglaravel.com#content-tobeused) that fails when `dump()` (and `dd()`) are used. Assuming you run tests as part of your build and deploy process, this will prevent `dump()` and `dd()` from hitting production. 2. [Selectively stage and commit changes](https://securinglaravel.com/security-tip-selectively-stage-and/) using `git add -p` or a visual git tool. This allows you to eyeball every changed line, and there is a good chance you'll spot the extra `dump()`/`dd()` in your diff. This won't catch newly added files. 3. If you work in team with other developers, start reviewing each others changes via Pull/Merge Requests. These reviews don't need to be huge, simply get another dev spend 30 seconds to eyeball your changes. There is a good chance they'll spot the inclusion of `dump()` or `dd()` that your brain is hiding from you. --- ## Stay One Step Ahead of Security Threats! Join **Securing Laravel* and arm yourself with the knowledge to protect your applications. Get [weekly security tips](https://securinglaravel.com/tag/tips/) delivered straight to your inbox, plus upgrade for access to [monthly In Depth articles](https://securinglaravel.com/tag/in-depth/) that dive deep into crucial security topics. By signing up, you're not just securing your code – you're supporting ongoing security research in the Laravel and PHP community! Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime.