Clickjacking in Laravel with Jwt Tokens

Clickjacking is a client-side UI redress attack where an invisible or disguised page element tricks a user into performing unintended actions. In a Laravel application that uses JWT tokens for stateless authentication, clickjacking remains possible despite strong token validation because the threat shifts from credential theft to user interaction manipulation. Laravel does not set frame-related headers by default, so if a page that carries a valid JWT (for example, an authenticated admin panel or a page that performs sensitive state changes via AJAX) can be embedded in an <iframe>, an attacker can overlay transparent controls on top of legitimate UI components.

With JWT tokens, the risk pattern changes slightly compared to cookie-based sessions. Since JWTs are typically stored in localStorage or sessionStorage and sent via Authorization headers, they are not automatically exposed to frame-based theft the way cookies with SameSite=None might be. However, if the frontend embeds an authenticated page inside an iframe (or an attacker tricks the user into interacting with a malicious site that includes your app via iframe), the user’s active JWT can be leveraged to make authenticated requests initiated through UI redressing. For example, an attacker might load your Laravel admin dashboard inside an iframe, overlay a “Confirm Transfer” button on a hidden form, and rely on the browser sending the JWT automatically with the request because credentials are included via Authorization headers or stored tokens in the same origin context.

Compounding this, if your Laravel frontend makes AJAX calls to APIs that rely on JWTs and does not enforce strict Content Security Policy (CSP) frame-ancestors, an attacker can craft a page that embeds your API endpoints directly. Even with JWTs, if your application surfaces sensitive actions behind simple GET endpoints or does not use anti-CSRF tokens for state-changing POST/PUT/DELETE requests, clickjacking can be used to trigger these actions unknowingly. The presence of JWTs does not prevent clickjacking; it changes the attacker’s goal from stealing the token to abusing the authenticated session the token represents through UI manipulation.

Real-world patterns mirror OWASP’s A05:2021 — Security Misconfiguration and A01:2027 — Injection (in the UI layer). Insecure default headers, permissive CSP, and missing X-Frame-Options or Content-Security-Policy frame-ancestors directives enable embedding. Developers sometimes assume JWTs mitigate CSRF and thereby neglect frame protection, which is a dangerous misconception. Therefore, a Laravel application using JWT tokens must explicitly defend against clickjacking by controlling framing and ensuring that sensitive actions require explicit user intent beyond mere token possession.

Remediation focuses on two layers: HTTP headers to prevent framing, and application-level practices to ensure JWT usage does not weaken clickjacking defenses. Start by enforcing frame-ancestors and related headers in Laravel so that pages that carry JWT-authenticated UI cannot be embedded maliciously.

1) Set security headers in Laravel

Configure your application to send X-Frame-Options and Content-Security-Policy frame-ancestors. In a typical Laravel setup, you can do this via middleware or a dedicated security headers middleware.

// app/Http/Middleware/SecurityHeaders.php
namespace App\Http\Middleware;

use Closure;

class SecurityHeaders
{
    public function handle($request, Closure $next)
    {
        $response = $next($request);
        // Prevent framing entirely
        $response->headers->set('X-Frame-Options', 'DENY');
        // Modern replacement: restrict which origins can frame this page
        $response->headers->set(
            'Content-Security-Policy',
            "frame-ancestors 'self'; frame-src 'none'; object-src 'none'"
        );
        return $response;
    }
}

Register this middleware early in the pipeline (e.g., in app/Http/Kernel.php) so it applies to authenticated routes, including those where JWT validation occurs.

2> Use SameSite and Secure flags on tokens where applicable

If your frontend sets tokens in cookies (for example, for SPA hydration), mark them as SameSite and Secure. For tokens stored only in localStorage and sent via Authorization headers, these flags are not applicable, but you should still avoid any cookie-based fallback that lacks these protections.

// Example when using cookie-based session alongside JWTs (not typical for pure JWT APIs)
// In config/session.php or when setting cookies manually
return [
    'same_site' => 'strict',
    'secure' => true,
    'http_only' => true,
];

3> Validate Origin and Referer for sensitive endpoints

Although not a replacement for header-based defenses, you can add origin checks in Laravel for critical actions. This complements JWT validation by ensuring requests originate from expected contexts.

// app/Http/Middleware/EnsureValidOrigin.php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class EnsureValidOrigin
{
    public function handle(Request $request, Closure $next)
    {
        $allowedOrigins = [
            'https://yourtrusteddomain.com',
            'https://app.yourtrusteddomain.com',
        ];
        $origin = $request->header('Origin');
        $referer = $request->header('Referer');
        if ($origin && !in_array($origin, $allowedOrigins, true)) {
            return response('Unauthorized', 403);
        }
        if ($referer && !in_array(parse_url($referer, PHP_URL_HOST), ['yourtrusteddomain.com'], true)) {
            return response('Unauthorized', 403);
        }
        return $next($request);
    }
}

4> Example JWT usage in Laravel (frontend fetch pattern)

Ensure that AJAX requests include the Authorization header and that your frontend does not embed authenticated pages in iframes. Below is a standard way to attach a JWT stored in localStorage to fetch requests.

// Example frontend JavaScript (not Laravel PHP)
const token = localStorage.getItem('jwt');
fetch('/api/transfer', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}`,
    },
    body: JSON.stringify({ to: '12345', amount: 100 }),
}).then(response => response.json()).then(data => console.log(data));

On the Laravel side, validate the JWT and ensure that state-changing endpoints use POST with proper intent confirmation. Do not rely on GET endpoints for actions that change state, regardless of token presence.