> ## 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: Disable Dev Tools on Prod
- URL: https://securinglaravel.com/security-tip-disable-dev-tools-on/
- Published: 2023-06-27T00:00:14.000Z
- Updated: 2025-04-15T04:29:25.000Z
- Description: [Tip#49] Dev tools are are really helpful, but they are still just dev tools. Don't install them on production... or anywhere world-accessible, if you can avoid it.
- Author: Stephen Rees-Carter
- Tags: Security Tips, Dev Tools, Workflow

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](https://laravel.com/docs/telescope?ref=securinglaravel.com), or [Clockwork](https://underground.works/clockwork/?ref=securinglaravel.com)…

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](https://laravel.com/docs/telescope?ref=securinglaravel.com#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 ](https://laravel.com/docs/10.x/telescope?ref=securinglaravel.com#dashboard-authorization)`viewTelescope`[ authorisation gate](https://laravel.com/docs/telescope?ref=securinglaravel.com#dashboard-authorization), and [Clockwork has a password you can configure](https://underground.works/clockwork/?ref=securinglaravel.com#docs-authentication).

**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 found this security tip useful,*** [***subscribe***](#/portal/signup) ***to get weekly*** [***Security Tips***](https://securinglaravel.com/tag/tips/) **straight to your inbox.* Upgrade to a* [*premium subscription*](#/portal/signup) *for exclusive monthly* [*In Depth articles*](https://securinglaravel.com/tag/in-depth/)*, or drop a coin in the* [*tip jar*](#/portal/support) *to show your support.*

*When was the last time you had a penetration test? Book a* [*Laravel Security Audit and Penetration Test*](https://stephenreescarter.net/laravel-security-audits-and-pentesting/?utm%5Fsource=securinglaravel.com)*, or a budget-friendly* [*Security Review*](https://stephenreescarter.net/laravel-security-reviews/?utm%5Fsource=securinglaravel.com)*!* 

*You can also connect with me on* [*Bluesky*](https://bsky.app/profile/valorin.bsky.social?ref=securinglaravel.com)*, or* [*other socials*](https://pinkary.com/@valorin?ref=securinglaravel.com)*, and check out* [*Practical Laravel Security*](https://practicallaravelsecurity.com/?utm%5Fsource=securinglaravel.com)*, my interactive course designed to boost your Laravel security skills.*