unathenticated end points (IDOR) solved

[annrose2277-glitch]

Related Issue

Closes #337

Summary

Updated the database schema to include a user_id column, linking every task to its creator.

Integrated jsonwebtoken to generate secure session tokens upon user login.

Created an authenticateToken middleware to protect previously exposed API routes.

Updated backend SQL queries to enforce strict ownership checks (e.g., WHERE id = ? AND user_id = ?), ensuring users can only alter their own data.

Changes Made

-Updated database schema: Added a user_id column to the tasks table to link records to their respective creators.

Implemented JWT authentication: Updated the /api/auth/login endpoint to generate and return a JSON Web Token (JWT) upon successful login.

Created auth middleware: Added an authenticateToken middleware in server.js to parse and validate the Authorization: Bearer header.

Secured API endpoints: Applied the auth middleware to POST /api/tasks, PUT /api/tasks/:id, and DELETE /api/tasks/:id.

Enforced ownership validation: Modified the SQL queries in the PUT and DELETE controllers to include WHERE id = ? AND user_id = ?, ensuring users can only mutate their own data and resolving the IDOR vulnerability.

• ...

Testing

Unauthenticated Request: Sent DELETE /api/tasks/{id} without a token. Verified the server rejects the request with a 401 Unauthorized status.

Cross-User Modification (IDOR attempt): Logged in as User A to get a valid token. Attempted to send a PUT request to update a task owned by User B. Verified the server rejects the action (returns 0 changes or 403 Forbidden) because the user_id does not match.

Valid Request: Sent a DELETE request for an owned task with a valid Bearer token. Verified the server returns 200 OK and the task is successfully removed from the database.

Screenshots

Add screenshots if UI changes exist.

Checklist

• Code follows project style
• Tested locally
• No unrelated changes included
• Documentation updated (if applicable)