/_profiler on a live site. Type it after any Symfony domain and sometimes it answers. This autumn the story went around, and I will not retell it. The lesson is bigger than one framework.
Think what a profiler actually stores. Every SQL query with parameters. Cookies and session data. Routes, controller names, request headers. Sometimes config values. A full X-ray of your application, nicely formatted, with search.
Now count how many sites have /_profiler or a debugbar open to the world because someone deployed with app_dev.php, or left debug = true in the production config. Not a rare exotic mistake. I saw it. I made it once, on a staging server that stayed reachable from outside longer than anyone planned.
The fix is not “restrict by IP”. IP filters are the second step. The first step is config separation that cannot fail silently. Production config must not contain the profiler at all. Not disabled. Absent. In Symfony terms: WebProfilerBundle is registered only for the dev environment in AppKernel. In Laravel terms: debugbar in require-dev, never in require.
Second step, the deploy checks it. One line in the deploy script that curls /_profiler and fails the deploy if it answers 200. Cheap and honest.
And the principle behind both. Diagnostics are for operators, not for the whole internet. You need production debugging, everyone does, so give it a separate door: logs, metrics, an internal admin behind auth. Not the developer toolbar on the public page.
The profiler is a great tool. On localhost.