Security Tip: Disable Dev Tools on Prod

Dev tools are awesome. They make our jobs so much easier, and using the right tool at the right time can cut hours of debugging pain. But they are also a huge security risk.

Consider Laravel Telescope, or Clockwork…

When you go to their website, the installation steps are as follows:

composer require laravel/telescope
php artisan telescope:install
php artisan migrate

composer require itsgoingd/clockwork

They are super simple to install, but it also introduces a security issue…

You’ve just installed a dev tool that will be installed on production. Yes, you need to manually enable it on production, but that’s a simple toggle in your .env file! Even if it starts disabled, that can easily change. Especially when someone needs to debug that weird issue that only happens on production.

These dev tools are not secure. They contain bucketloads of internal information, debug information, and can easily be used to scrape data and hijack sessions. This results in a data breach and customer confidence being destroyed.

They aren’t even safe on staging/testing sites when they are world-accessible. If an attacker can find your Telescope instance on staging, they can hijack sessions, access test data, and use that to pivot into your production environment, or even directly infect developers and gain access that way.

My recommendation is to always install dev tools into require-dev in your composer.json, rather than the default require section.

This means using the --dev flag when you install:

composer require laravel/telescope --dev

and then always using --no-dev when installing composer dependencies in world-accessible environments:

composer install --no-dev ...

This prevents dev dependencies from being installed, so they cannot be enabled and (ab)used.

If you need dev tools on staging/testing, then disable auto-discovery of the package and manually register the service provider conditionally within your AppServiceProvider. This means that even though the code might exist on production, it isn’t loaded and cannot be enabled and (ab)used.

Laravel Telescope has great instructions for a local only installation, which you can use as a guide for this process.

Register in AppServiceProvider:

/**
 * Register any application services.
 */
public function register(): void
{
    if ($this->app->environment('local')) {
        $this->app->register(\Laravel\Telescope\TelescopeServiceProvider::class);
        $this->app->register(TelescopeServiceProvider::class);
    }
}

Disable auto-discovery:

"extra": {
    "laravel": {
        "dont-discover": [
            "laravel/telescope"
        ]
    }
},

You should also ensure you check the provided authorisation options provided by the dev tool, and enable those when working outside local dev environments. For example, Telescope has the viewTelescope authorisation gate, and Clockwork has a password you can configure.

But you should seriously consider if you need the dev tools in a world-accessible environment. Does the benefit for occasional debugging outweigh the risk if someone gets access to it?

Something to think about…

If you've made it this far, please share this Security Tip and Securing Laravel with your Laravel friends, colleagues, and enemies! The more folks we have learning about security, the more secure code will be written, and the safer the whole community and our users will be. Also, if you tag me I'll give it a retweet.

Find me on: Pinkary, Twitter, Mastodon, LinkedIn, & Threads.