Hey there! Let's break down your Laravel 5.6 session and cookie security questions one by one, with practical advice tailored to your use case:

Using session(['ses_var' => 123]) to set a session variable and checking if(!empty(session('ses_var'))) to verify login status is secure and recommended. Here's why:

• Laravel stores session data server-side (default is file storage, but you can use Redis/database for scalability), so the client only receives a cryptographically signed session ID cookie.
• Since you've already configured Secure, Strict, and HTTP settings in session.php, you're adding extra critical layers:
  • secure ensures the session cookie only travels over HTTPS
  • httponly prevents JavaScript access (mitigates XSS attacks)
  • same_site blocks cross-site cookie misuse (mitigates CSRF attacks)
• Tampering with the session ID cookie will invalidate it immediately, so attackers can't forge or hijack a valid session easily.

Let's split this into two key parts:

Cookie Validation #

When you use Laravel's Cookie::queue() to set cookies, they're automatically encrypted and signed (thanks to the EncryptCookies middleware enabled by default). This means:

• If a client tampers with a_cookie, Cookie::get('a_cookie') will return null or an invalid value, so your check if(Cookie::get('a_cookie') == "some_value") is safe—as long as you use Laravel's Cookie facade exclusively (avoid raw $_COOKIE access, since it returns unencrypted, unvalidated data).

Storing Cookie Values in the Database #

This is safe only if:

• The cookie value isn't sensitive (e.g., non-sensitive user preferences are fine, but avoid storing user IDs, auth tokens, or personal data)
• You're still using Laravel's encrypted/signed cookies to prevent tampering before storing
• You don't rely on this stored value as a source of truth for critical operations (like login status)—always use server-side session data for that.

Your current logout code has a few red flags:

FOREACH($_COOKIE AS $key => $value) { SETCOOKIE($key,$value,TIME()-10000,"/"); } 
Session::flush();

• Don't delete all cookies: This will wipe non-Laravel cookies (like third-party analytics) which isn't necessary, and might break expected behavior for your users.
• Raw PHP setcookie can conflict with Laravel: Laravel's cookie handling accounts for your app's domain, path, and encryption settings—raw setcookie might not, leading to leftover invalid cookies.
• Session::flush() alone isn't enough: This clears session data, but doesn't invalidate the session ID (risk of session fixation attacks).

Better Logout Implementation #

Use Laravel's built-in methods for a secure, clean logout:

// Invalidate the current session (invalidates the session ID to prevent reuse)
Session::invalidate();
// Regenerate the CSRF token to block potential reuse
Session::regenerateToken();
// Remove only Laravel's necessary cookies
Cookie::queue(Cookie::forget('laravel_session'));
Cookie::queue(Cookie::forget('XSRF-TOKEN'));

This ensures the old session can't be reused, cleans up only relevant cookies, and aligns with Laravel's security best practices.

Your instinct is correct—always use server-side sessions for critical state like login status. Here's why sessions are superior for core control:

• Session data lives on your server, so clients can't view or modify it directly (unlike cookies, even encrypted ones)
• Sessions are easier to invalidate (e.g., on logout, password change)
• You can store more complex, sensitive data in sessions without exposing it to the client

Cookies should only be used for non-critical, client-side preferences (like theme selection) or as a transport for the session ID itself.

• Keep the EncryptCookies middleware enabled (don't disable it in app/Http/Kernel.php)—this protects all Laravel-managed cookies.
• In production, enforce secure => true in session.php to ensure cookies only travel over HTTPS.
• Avoid storing any sensitive data in cookies, even if encrypted.
• Never trust raw $_COOKIE values—always use Laravel's Cookie::get() to retrieve decrypted, validated cookie data.
• For login management, consider using Laravel's built-in authentication system (Auth facade) instead of rolling your own—it's battle-tested and handles edge cases like session invalidation, password hashing, and CSRF protection automatically.

内容的提问来源于stack exchange，提问作者Some Coder