[FEAT] Create a reusable ownership verification dependency for protected resources

[Devexhhh]

Summary

Introduce a reusable ownership verification dependency for protected resources to centralize authorization logic. This will eliminate duplicated ownership checks across endpoints while ensuring consistent enforcement of per-owner access control.

Problem

The recent introduction of owner_id isolation requires endpoints to verify that the requesting owner matches the resource owner. If each route performs this check independently, the authorization logic becomes duplicated, increasing maintenance effort and the risk of future endpoints accidentally omitting ownership validation.

Proposed solution

Create a reusable FastAPI dependency (or helper) that resolves the current owner, retrieves the requested resource, verifies ownership, and either returns the resource or raises an appropriate HTTP exception.

Endpoints can then depend on this shared authorization layer instead of implementing ownership checks individually, improving consistency and reducing code duplication.

Suggested scope

If you already know the likely implementation area, mention it here:

• Suggested files or directories:

  • backend/auth.py (or the module containing ownership helpers)
  • Resource service/repository modules
  • API route handlers for tasks, findings, reports, exports, and delete operations

• Related route, page, component, API, or plugin:

  • Protected API endpoints that currently perform manual owner_id verification

Acceptance criteria

• Introduce a reusable dependency/helper for ownership verification.
• Refactor existing protected endpoints to use the shared dependency instead of duplicating authorization logic.
• Preserve existing authorization behavior and error responses, with no regressions in single-user deployments.

Test plan

• Run the existing test suite to ensure no regressions.
• Verify that a resource owner can successfully access, modify, export, or delete their own resources.
• Verify that requests attempting to access another owner's resources are rejected with the expected HTTP status.
• Confirm that deployments relying on the default owner continue to function as before.

Alternatives considered

• Continue performing ownership checks within each route handler. While simple, this duplicates logic and makes it easier for future endpoints to accidentally omit authorization checks.
• Introduce ownership validation within the data access layer. Although this centralizes enforcement, it may reduce flexibility for endpoints with different authorization requirements.

Additional context

This is a follow-up improvement to the per-owner authorization model introduced to mitigate Broken Object Level Authorization (BOLA/IDOR) vulnerabilities. Centralizing ownership verification makes the authorization layer easier to maintain and reduces the likelihood of future security regressions.