filtering out the staff details to non-staff roles hence fixing insec…

[atharv2-git]

Base Branch: 9.x

Note: This PR is made to doubtfire-lms/doubtfire-api as an upstream contribution to resolve the IDOR vulnerability, after peer reviews, AppAttack verification, and mentor approval.

Description

This PR resolves an Insecure Direct Object Reference (IDOR) vulnerability where non-privileged users (such as students) could access sensitive staff-related data (e.g., main_convenor_id, tutor_id, email, full_name) through the /api/units/:id endpoint.

Access to these fields is now strictly role-based, ensuring that only authorized users (e.g., staff, convenors, admin, tutor) can access privileged information.

Reference PRs

• Original peer-reviewed PR: thoth-tech/doubtfire-api PR
• Background documentation: Fix IDOR Vulnerability Documentation

---

Root Cause

The exposure originated in the Entities::UnitEntity class, which serializes backend models to JSON for API responses. It previously lacked role checks for sensitive fields, allowing information leakage to unauthorized users.

---

Fix Summary

• Introduced role-based filtering logic in UnitEntity to conditionally expose:
  • :staff
  • :main_convenor_id
  • :tutor_id
  • :email
  • :overseer_image_id
• Ensured correct access enforcement without breaking front-end communication or staff privileges.

---

Validation Summary

• Validated via Postman with different user roles (Student, Convenor, Admin).
• Students can no longer view restricted fields in /api/units/:id or related endpoints.
• Staff can still access appropriate data required for unit coordination and oversight.
• Screenshots confirming before-and-after behavior included below:

Before: Student Accessing Staff Data

---

After: Staff Data Hidden from Students

---

After: Convenor Access Confirmed

---

Peer Review & Approval

• @Darryl021 (AppAttack), @lachlan-robinson, @ibi420 - Verified proper RBAC enforcement and data protection, and Validated using Postman.
• @aNebula - Approved upstream PR creation and integration.

---

Type of Change

• Security fix (non-breaking)
• Refactor (minor backend improvement)

---

How Has This Been Tested?

• Verified API responses via Postman with different roles
• Manually tested /api/units/:id and /api/unit_roles
• Ensured no regression in app functionality for staff and tutors
• Confirmed correct behavior across session and role transitions

---

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented relevant logic where needed
• I have made corresponding documentation updates
• I have linked this upstream PR to prior internal work and testing documentation

[b0ink]

It’s generally not an issue, as most students already have staff email accounts via the university’s unit site.