Sign in Subscribe
Security Tips

Security Tip: Intercepting dump() Could Expose Production!

[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!

Stephen Rees-Carter

Stephen Rees-Carter

— 2 min read
Security Tip: Intercepting dump() Could Expose Production!

Laravel Herd Pro and Telescope 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 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 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.

Read more