Task and report APIs lack a user/owner authorization model

[ionfwsrijan]

Problem

Tasks, findings, and reports are globally addressable by task/report IDs without per-user ownership enforcement.

Evidence

Affected code:

• backend/secuscan/routes.py
• backend/secuscan/database.py

The database stores tasks, findings, and reports, but task operations are not consistently scoped to an authenticated owner.

Impact

If SecuScan is deployed beyond single-user localhost, one user can enumerate or download another user’s scan results, including sensitive targets, raw outputs, findings, and reports.

Expected fix

• Introduce authenticated user/workspace ownership for tasks
• Store owner_id on tasks/reports/findings
• Scope all list/get/delete/report endpoints by owner
• Add tests for cross-user task/result/report access

[ionfwsrijan]

@utksh1 You may review and assign me this issue

[smirk-dev]

Hi! I'd like to work on this as a GSSoC 2026 contributor.

This is a real BOLA (Broken Object Level Authorization) vulnerability. Any authenticated user can access or delete another user's scans/reports just by guessing or enumerating task IDs.

My approach:

• Add an owner_id field to the tasks, findings, and reports tables, populated with the authenticated user's ID at creation time
• Add an authorization check in backend/secuscan/routes.py for all GET, DELETE, and report download endpoints: compare the requesting user's ID against owner_id and return HTTP 403 if they don't match
• Write tests that confirm cross-user access is denied (User A cannot access User B's scan results)

I work with Python/FastAPI backends and have experience with ownership-scoped authorization patterns. Could you please assign this issue to me?

[madsysharma]

Hi @utksh1 , I would like to work on this as part of GSSoC 2026.