Description
The backend currently suffers from a critical Insecure Direct Object Reference (IDOR) and broken authentication vulnerability.
The endpoints /generate-blog, /publish-blog, /dashboard/stats, /dashboard/history, and /dashboard/record rely on the require_user() function, which simply extracts an email address from the X-User-Email HTTP header. These endpoints completely fail to verify the user's JWT token.
Because there is no cryptographic verification that the user actually owns the email provided in the header, an attacker can simply spoof the X-User-Email header in their HTTP request to instantly view any victim's private dashboard history, or maliciously trigger AI generation and publish blogs under the victim's account without needing a password or valid session.
Steps To Reproduce
Open a terminal or PowerShell instance (no login required).
Execute a raw HTTP request to one of the protected dashboard endpoints, spoofing the header with any victim's email:
powershell
Invoke-RestMethod -Uri "http://localhost:10000/dashboard/stats" -Headers @{"X-User-Email"="victim_user@example.com"}
Observe that the backend instantly returns a 200 OK response containing the private platform counts, total posts, and recent activity belonging to that victim, completely bypassing the JWT authentication layer.
Expected Behavior
These endpoints should securely extract the user's identity from a cryptographically signed JWT. Requests missing a valid Bearer token in the Authorization header, or requests where the token is expired/invalid, should be immediately rejected with a 401 Unauthorized error. The X-User-Email header logic should be entirely removed.
Environment
OS: Any
Browser: N/A (Backend API Vulnerability)
Version: Latest main branch
Description
The backend currently suffers from a critical Insecure Direct Object Reference (IDOR) and broken authentication vulnerability.
The endpoints /generate-blog, /publish-blog, /dashboard/stats, /dashboard/history, and /dashboard/record rely on the require_user() function, which simply extracts an email address from the X-User-Email HTTP header. These endpoints completely fail to verify the user's JWT token.
Because there is no cryptographic verification that the user actually owns the email provided in the header, an attacker can simply spoof the X-User-Email header in their HTTP request to instantly view any victim's private dashboard history, or maliciously trigger AI generation and publish blogs under the victim's account without needing a password or valid session.
Steps To Reproduce
Open a terminal or PowerShell instance (no login required).
Execute a raw HTTP request to one of the protected dashboard endpoints, spoofing the header with any victim's email:
powershell
Invoke-RestMethod -Uri "http://localhost:10000/dashboard/stats" -Headers @{"X-User-Email"="victim_user@example.com"}
Observe that the backend instantly returns a 200 OK response containing the private platform counts, total posts, and recent activity belonging to that victim, completely bypassing the JWT authentication layer.
Expected Behavior
These endpoints should securely extract the user's identity from a cryptographically signed JWT. Requests missing a valid Bearer token in the Authorization header, or requests where the token is expired/invalid, should be immediately rejected with a 401 Unauthorized error. The X-User-Email header logic should be entirely removed.
Environment
OS: Any
Browser: N/A (Backend API Vulnerability)
Version: Latest main branch