How to Fix an Exposed Laravel Telescope Dashboard

Your Laravel Telescope dashboard is publicly accessible in production, exposing requests, queries, and application data. Secure it now.

Critical severity Application Security Updated 2026-03-01 Markdown

Laravel Telescope was introduced in 2018 as a first-party debugging assistant designed for the local development environment. Unlike third-party APM tools, Telescope hooks directly into the framework and records everything: every HTTP request with full headers and payloads, every database query with bound parameters, every Redis command, every queued job payload, every sent email, and every model change event. This comprehensive recording is exactly what makes it so useful during development — and so dangerous when exposed.

The attack scenario requires no technical skill. An attacker visits /telescope and immediately sees a real-time stream of everything happening in your application. They can watch users log in (capturing credentials from POST payloads), read JWT tokens from API request headers, extract database queries to understand your schema, pull API keys from outgoing HTTP requests to third-party services, and read user data from model events. No exploitation is required — Telescope serves all this data through a polished UI.

Telescope exposure is common because it installs as a production dependency by default, the service provider auto-registers itself, and the default authorization gate allows access only to localhost — which provides no protection for web-accessible production servers. The /telescope path is widely known and actively scanned by security researchers and attackers alike. In bug bounty programs, an exposed Telescope dashboard is consistently rated critical because it can expose the credentials and session tokens needed to take over every user account in the system.

The Problem

An exposed Telescope dashboard allows anyone to view all incoming requests, database queries, cache operations, scheduled tasks, and application logs in real time. Telescope is a powerful debugging tool that records everything happening in your application, and public access gives attackers complete visibility into your application internals, including user data and authentication tokens.

How to Fix

1
Restrict Telescope access with the gate
In app/Providers/TelescopeServiceProvider.php, define the authorization gate:
```
protected function gate(): void
{
    Gate::define('viewTelescope', function ($user) {
        return in_array($user->email, [
            'admin@yourdomain.com',
        ]);
    });
}
```
This ensures only specified users can access /telescope when authenticated.

Disable Telescope in production entirely

If you do not need Telescope in production, disable it. In your .env:

TELESCOPE_ENABLED=false

Or conditionally register it only in local environments. In config/telescope.php:

'enabled' => env('TELESCOPE_ENABLED', false),

And in TelescopeServiceProvider:

public function register(): void
{
    if (! config('telescope.enabled')) {
        return;
    }

$this->hideSensitiveRequestDetails();
    Telescope::night();
}

3
Block the route at the web server level
As an additional layer, block /telescope in your web server config. In Nginx:
```
location /telescope {
    deny all;
    return 404;
}
```
```
In Apache .htaccess:
```
```
RewriteRule ^telescope - [F,L]
```
This provides defense in depth even if the Laravel-level gate is misconfigured.

How to Verify

Open yourdomain.com/telescope in an incognito browser window (not logged in). You should see a 403 Forbidden or 404 Not Found page, not the Telescope dashboard. Also test the API route:

curl -I https://yourdomain.com/telescope/requests

This should return 403 or 404.

Prevention

Add TELESCOPE_ENABLED=false to your production .env template and deployment checklist. Only install Telescope as a dev dependency with composer require laravel/telescope --dev. Use StackShield to monitor for exposed Telescope dashboards continuously.

Frequently Asked Questions

What data does Telescope expose?

Telescope records and displays HTTP requests with headers and payloads, database queries with bindings, Redis commands, scheduled task output, queue job data, log entries, mail content, notifications, cache operations, and model events. This includes sensitive user data, authentication tokens, and internal application state.

Should I use Telescope in production at all?

Telescope is useful for production debugging but should only be enabled temporarily and always behind authentication. For ongoing production monitoring, dedicated tools like Laravel Pulse, Sentry, or Flare are better suited as they are designed for production use with proper access controls.

How do I safely access Telescope on a production server when I need to debug?

Enable Telescope temporarily via TELESCOPE_ENABLED=true in your .env, ensure the authorization gate restricts access to your admin email, clear the config cache, investigate your issue, then re-disable it. Alternatively, use an SSH tunnel: ssh -L 8080:localhost:8080 user@server and access the app locally through the tunnel, where Telescope's localhost gate works correctly.

What is the difference between Telescope and Laravel Pulse?

Telescope records detailed request-level data for debugging individual issues — it is a development tool. Laravel Pulse is designed for production monitoring, showing aggregated metrics like average response times, error rates, queue health, and slow queries without recording sensitive request payloads. Pulse is the appropriate choice for always-on production visibility.

Does Telescope affect application performance?

Yes, noticeably. Telescope adds hooks to nearly every framework component and writes every request, query, and event to its database. On a busy production application, this can add hundreds of milliseconds of overhead and significantly increase database writes. This is another reason to keep Telescope disabled in production.

Related Guides

Critical

Is your Laravel app exposed right now?

34% of Laravel apps we scan have at least one critical issue. Most teams don't find out until something breaks. Our free scan checks your live application in under 60 seconds.

18% have debug mode on

72% missing security headers

12% have exposed .env

Scan My App Free No signup required. Results in 60 seconds.