Greetings friends! We’ve finished our Top 10 series last week, so let’s move onto something new. This week I want to remind everyone about dev tools - specifically about not having them installed on production! For our next big series, I’m planning on debunking the different myths and claims that “PHP is insecure” - I’m still gathering sources, so please send any claims and myths in my direction! 🔥🤓

I do have two other exciting things to tell you about, but I’ll put them at the end so we can get into this week’s tip. Don’t forget to check them out!

🛡️ Thinking about a Laravel Security Audit and Penetration Test this year? I’m now booked out until October and have limited time available in November and December… Book in now before it’s too late! 🕵️

Looking to learn more?
⏩ OWASP Security Tip: A09:2021 – Security Logging and Monitoring Failures
▶️ OWASP In Depth: A08:2021 – Software and Data Integrity Failures

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 production1.

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 data2, and use that to pivot into your production environment3, 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`. That 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…

Security Reviews and Referrers!

A challenge I’ve been trying to solve for ages is how to offer security audits to solo devs and small teams who don’t have the budget for a full audit. My solution is a new service I’m calling “Laravel Security Reviews”, which is a low cost security review that involves checking the basics, configuration, and common weaknesses found in Laravel apps, to find vulnerabilities and misconfigurations that can have a huge impact on your app.

I’m still in the early days of planning it out, however to test out the idea, I’m accepting 5 apps for review, and wanted to offer those slots to my subscribers first! If you’re interested, you can find the details here or send me an email!

And, one more thing…

There is a cool new Substack feature: Subscriber Referrals!

This is a new feature that allows you to support Securing Laravel by promoting it to your friends and colleagues. Use the “Refer a friend” or “Share” button on a post and you’ll get credit for anyone who signs up. When you get 3 referrals, you’ll get 1 month free paid subscription, 5 referrals gives 3 months, and 25 referrals gives you 6 months!

So what are you waiting for?