Describe the bug
The application's session management and token storage logic contain security anti-patterns that expose user sessions to Cross-Site Scripting (XSS) attacks. Specifically:
- Insecure Session Cookie: The PHP session cookie (
PHPSESSID) is not configured with the HttpOnly flag. This means the session identifier is accessible to any client-side JavaScript.
- Insecure Token Storage Logic: The frontend code (
src/hooks/useUserData.ts) explicitly contains logic to store authentication tokens in localStorage if they are present in API responses. localStorage lacks the protection of HttpOnly, making any stored credentials vulnerable to theft via XSS.
Steps to reproduce
- Log in to Open Scrobbler.
- Open the browser's Developer Tools (F12).
- Navigate to the Console tab.
- Run
document.cookie and observe that the PHPSESSID cookie is visible in the output.
- Inspect
src/hooks/useUserData.ts:57 to see the logic that saves tokens to localStorage.
Expected behavior
All session-identifying information (including the PHP session cookie and any authentication tokens) should be handled using HttpOnly cookies. These are protected by the browser and cannot be read by JavaScript, which is a critical defense-in-depth measure against XSS attacks.
Device
Platform (please complete the following information):
- Operating system: All
- Browser: All
- Version: 2.13.0
Additional context
I am willing to propose a PR to harden the authentication flow by:
- Updating
public/api/v2/inc/session.php to set the HttpOnly, Secure, and SameSite=Strict flags on the session cookie.
- Configuring the Axios client with
withCredentials: true to support secure cookie-based requests.
- Removing manual token management and
localStorage storage logic from the frontend.
- Adding a one-time cleanup to purge any legacy tokens from
localStorage.
This follows OWASP best practices for secure session management.
Describe the bug
The application's session management and token storage logic contain security anti-patterns that expose user sessions to Cross-Site Scripting (XSS) attacks. Specifically:
PHPSESSID) is not configured with theHttpOnlyflag. This means the session identifier is accessible to any client-side JavaScript.src/hooks/useUserData.ts) explicitly contains logic to store authentication tokens inlocalStorageif they are present in API responses.localStoragelacks the protection ofHttpOnly, making any stored credentials vulnerable to theft via XSS.Steps to reproduce
document.cookieand observe that thePHPSESSIDcookie is visible in the output.src/hooks/useUserData.ts:57to see the logic that saves tokens tolocalStorage.Expected behavior
All session-identifying information (including the PHP session cookie and any authentication tokens) should be handled using HttpOnly cookies. These are protected by the browser and cannot be read by JavaScript, which is a critical defense-in-depth measure against XSS attacks.
Device
Platform (please complete the following information):
Additional context
I am willing to propose a PR to harden the authentication flow by:
public/api/v2/inc/session.phpto set theHttpOnly,Secure, andSameSite=Strictflags on the session cookie.withCredentials: trueto support secure cookie-based requests.localStoragestorage logic from the frontend.localStorage.This follows OWASP best practices for secure session management.