Laravel Telescope in Production: Security Risks You Need to Know

Laravel Telescope is one of the best debugging tools in the Laravel ecosystem. It gives you a real-time window into everything your application does: every HTTP request, every database query, every queued job, every mail sent, every cache hit and miss, every log entry, and more.

That makes it incredibly powerful for development. And incredibly dangerous in production.

What Telescope Records

Telescope captures detailed data across these watchers:

This is a complete record of your application's internal behavior.

What an Attacker Learns from Exposed Telescope

An attacker who finds your Telescope dashboard at /telescope gets the equivalent of full application access.

From Requests: Every API endpoint, Authorization headers with Bearer tokens, request bodies with user credentials and personal data, session data with CSRF tokens.

From Queries: Your entire database schema. Table names, column names, relationships. Query bindings expose actual data values.

From Jobs and Mail: Job payloads with user data, password reset tokens, invitation links, full transactional email content. Enough to hijack accounts.

From Logs and Exceptions: Full directory structure, file paths, class names. Logged errors may contain credentials and API responses.

How to Check If Telescope Is Exposed

Open an incognito browser window and navigate to:

https://yourdomain.com/telescope

If you see the dashboard without logging in, it's exposed. Also check the API:

curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/telescope/telescope-api/requests

A 200 response means the API is open.

How to Secure Telescope

Option 1: Disable in Production (Safest)

TELESCOPE_ENABLED=false

Or conditionally register in TelescopeServiceProvider:

public function register(): void
{
    if ($this->app->environment('local')) {
        $this->app->register(TelescopeServiceProvider::class);
    }
}

Option 2: Authorization Gate

protected function gate(): void
{
    Gate::define('viewTelescope', function ($user) {
        return in_array($user->email, [
            'admin@yourdomain.com',
        ]);
    });
}

Option 3: IP Restriction + Auth

protected function gate(): void
{
    Gate::define('viewTelescope', function ($user) {
        $allowedIps = ['203.0.113.50', '198.51.100.25'];
        return in_array(request()->ip(), $allowedIps)
            && in_array($user->email, ['admin@yourdomain.com']);
    });
}

Option 4: Filter Sensitive Data

If you must run Telescope in production, limit what it records:

use Laravel\Telescope\IncomingEntry;
use Laravel\Telescope\Telescope;

Telescope::filter(function (IncomingEntry $entry) {
    if (app()->environment('local')) {
        return true;
    }
    return $entry->isReportableException() ||
           $entry->isFailedRequest() ||
           $entry->isFailedJob();
});

Telescope::hideRequestParameters(['password', 'password_confirmation']);
Telescope::hideRequestHeaders(['authorization', 'cookie']);

Better Alternatives for Production

Laravel Pulse is built for production monitoring. It shows aggregated performance metrics without storing sensitive request-level data.

Error tracking (Sentry, Flare, Bugsnag) captures exceptions with proper access controls.

External monitoring like StackShield detects exposed Telescope dashboards from the outside, alerting you before an attacker finds it.

The Bottom Line

Telescope is an excellent development tool, not a production monitoring tool. Disable it in production, or lock it down with multiple layers of access control. Set up external monitoring to catch the inevitable misconfiguration before someone else does.