Description
Both GET /api/tasks and GET /api/messages are registered without any authentication middleware in backend/routes/tasks.routes.js and backend/routes/chat.routes.js respectively. Any unauthenticated HTTP client can retrieve the full task list and full chat history of the workspace.
// tasks.routes.js
router.get("/", getTasks); // no authenticateUser
// chat.routes.js
router.get("/", getMessages); // no authenticateUser
Both controllers fetch all records from Supabase with no user or project scope filter, so the entire dataset is exposed.
Steps to Reproduce
- Start the FlowForge backend server.
- Send
GET /api/tasks with no Authorization header.
- Observe that all task records are returned (id, title, description, status, position).
- Send
GET /api/messages with no Authorization header.
- Observe that all chat messages are returned (text, username, image, audio, created_at).
Expected Behavior
Both endpoints should require a valid user session before returning any data. The pattern used for the mutation endpoints (router.post("/", authenticateUser, createTask)) should be applied to the GET endpoints too:
router.get("/", authenticateUser, getTasks);
router.get("/", authenticateUser, getMessages);
Actual Behavior
All tasks and all chat messages are publicly readable without authentication.
Root Cause
In both route files, the GET handler is registered without the authenticateUser middleware that protects every other verb. This is likely an omission when the middleware was first added.
A secondary issue exists in the same files: POST / is registered twice - once with authenticateUser and once with only validateMessage / validateTask. Express uses the first matching registration, making the second one silently dead code. This should be collapsed into a single registration that applies both middleware in order:
router.post("/", authenticateUser, validateMessage, sendMessage);
Environment
- Backend: Node.js / Express
- Files:
backend/routes/tasks.routes.js, backend/routes/chat.routes.js
Additional Context
Expected NSOC points: level3 (security vulnerability exposing all workspace data publicly)
Suggested labels: bug, NSoC'26, level3
Checklist:
Description
Both
GET /api/tasksandGET /api/messagesare registered without any authentication middleware inbackend/routes/tasks.routes.jsandbackend/routes/chat.routes.jsrespectively. Any unauthenticated HTTP client can retrieve the full task list and full chat history of the workspace.Both controllers fetch all records from Supabase with no user or project scope filter, so the entire dataset is exposed.
Steps to Reproduce
GET /api/taskswith no Authorization header.GET /api/messageswith no Authorization header.Expected Behavior
Both endpoints should require a valid user session before returning any data. The pattern used for the mutation endpoints (
router.post("/", authenticateUser, createTask)) should be applied to the GET endpoints too:Actual Behavior
All tasks and all chat messages are publicly readable without authentication.
Root Cause
In both route files, the GET handler is registered without the
authenticateUsermiddleware that protects every other verb. This is likely an omission when the middleware was first added.A secondary issue exists in the same files:
POST /is registered twice - once withauthenticateUserand once with onlyvalidateMessage/validateTask. Express uses the first matching registration, making the second one silently dead code. This should be collapsed into a single registration that applies both middleware in order:Environment
backend/routes/tasks.routes.js,backend/routes/chat.routes.jsAdditional Context
Expected NSOC points: level3 (security vulnerability exposing all workspace data publicly)
Suggested labels:
bug,NSoC'26,level3Checklist: