bug: Unauthenticated API Endpoints & Broken Access Control (IDOR) Description

[annrose2277-glitch]

Problem

Describe the bug clearly.
The backend API (server.js) contains authentication routes (/api/auth/signup and /api/auth/login), but the actual task management endpoints (POST /api/tasks, PUT /api/tasks/:id, DELETE /api/tasks/:id) have absolutely no authentication middleware or ownership checks.

Because the tasks table does not tie a task to a specific user_id, any visitor can send a direct HTTP request to update or permanently delete any task in the database simply by guessing or knowing the task_id. This is a textbook Insecure Direct Object Reference (IDOR) vulnerability.

Current Behavior

Currently, the task management API endpoints are completely public. If a malicious actor discovers or guesses a valid task_id, they can send a PUT or DELETE request to the API without providing any session token, cookie, or authorization header. The server blindly accepts the request and modifies or deletes the target task, regardless of who created it.

Expected Behavior

Authentication: All /api/tasks endpoints should require a valid authentication token (e.g., JWT) to be accessed. Unauthorized requests must be rejected with a 401 Unauthorized status.

Authorization (Ownership): The database schema should associate every task with a user_id. When a PUT or DELETE request is made, the server must verify that the authenticated user making the request is the true owner of that specific task_id. If they are not, the server must reject it with a 403 Forbidden status.

Steps to Reproduce

Open the application and create a task normally. Use the browser's Developer Tools (Network Tab) to find the generated task_id for that task.

Open an API testing tool like Postman, Insomnia, or a standard terminal (using cURL).

Ensure you are not logged in and have no authorization headers or cookies set in your API tool.

Send a DELETE request to /api/tasks/{task_id} (replace {task_id} with the ID found in Step 1).

Observe that the server returns a 200 OK (or success message) and the task is successfully deleted from the database, bypassing all security.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

• Browser: Any API Client (Postman, cURL) or Browser
• Version: [e.g. 22]

Additional Context

To resolve this, the database schema must be updated immediately to include a user_id foreign key in the tasks table. Additionally, an authentication middleware (e.g., verifying a JWT) must be written and injected into the task routes in server.js. Database queries in the controllers must be updated to include WHERE id = ? AND user_id = ? to guarantee data isolation between users.

[annrose2277-glitch]

/assign PR#337 @Charushi06
How to Solve It:
You need to introduce JSON Web Tokens (JWT) to secure the routes and map tasks to users.

Update Database Schema: Modify the tasks and subjects table creation in database.js to include a user_id column.

Implement JWT Authentication:

Install jsonwebtoken: npm install jsonwebtoken

Update /api/auth/login to sign and return a token instead of just a success message.

Create Auth Middleware: Add a middleware function in server.js to verify the token:

const jwt = require('jsonwebtoken');

function authenticateToken(req, res, next) {
const authHeader = req.headers['authorization'];
const token = authHeader && authHeader.split(' ')[1];
if (token == null) return res.sendStatus(401);

jwt.verify(token, process.env.JWT_SECRET || 'secret_key', (err, user) => {
if (err) return res.sendStatus(403);
req.user = user;
next();
});
}

Protect the Routes: Apply this middleware to the CRUD endpoints and update the SQL queries to include WHERE id = ? AND user_id = ?

app.delete('/api/tasks/:id', authenticateToken, (req, res) => {
db.run(
'DELETE FROM tasks WHERE id = ? AND user_id = ?',
[req.params.id, req.user.email],
function (err) { ... }
);
});
```

---

[Udayan6611]

Hi @Charushi06,

I noticed this critical IDOR vulnerability is currently unassigned. Because this is a severe security flaw leaving the API exposed, I have mapped out an exact implementation plan tailored to your Express and SQLite architecture to patch it. I would love to tackle this under GSSoC/NSoC.

Proposed Implementation Plan:

Schema Update (database.js): Add a user_id foreign key to the tasks table schema to tie every task to its original creator.

Auth Middleware (server.js): Implement and inject JWT-based authentication middleware to protect the POST, PUT, and DELETE endpoints on /api/tasks. Unauthenticated requests will return a 401 Unauthorized.

Controller Authorization (Ownership Check): Update the SQLite queries to enforce strict ownership (e.g., WHERE id = ? AND user_id = ?) to ensure a user can only delete or modify their own tasks, returning a 403 Forbidden for IDOR attempts.

If this approach aligns with the repository's architecture, please let me know and I can get a PR up quickly!

/assign