Responsible Disclosure After Viewing Another Student's Records
During lunch, a high-school student in the cybersecurity club logs into the school portal and notices the URL https://portal.example.edu/grades?student_id=1024. The student changes the value to 1025 and sees another student's schedule and grades. No data is edited. The student takes a screenshot, tells a friend, and the friend repeats the change on a library computer. A teacher overhears them laughing about it. The district acceptable-use policy prohibits unauthorized access to accounts and data, and the portal is used for legally protected education records. The student says, 'I was just testing security; I did not change anything.' The teacher must decide what to do next and how to handle the technical issue without encouraging further exploration.
1. Evaluate the student's actions using responsible-disclosure and least-privilege principles. What should the teacher direct the student to do immediately, and what should the student not do?
Read the worked answer
Changing 1024 to 1025 was unauthorized access, even though no data was edited. The student accessed another student's protected education records, which the acceptable-use policy and privacy law treat seriously. Under least privilege, a user should see only their own records, and the portal should not trust a client-supplied student_id for authorization. Responsible disclosure means stopping immediately, not testing more IDs, not sharing the screenshot or technique, preserving the evidence with a timestamp, and reporting privately to IT/security and an administrator. The friend should also stop and report. The teacher should direct the student to write a factual timeline, hand over the screenshot, and avoid discussing it publicly. The teacher should not encourage further exploration on live data; any follow-up testing should be authorized, controlled, and use test accounts.
2. Recommend the technical fix and a disclosure process. Include at least three controls and how to verify them.
Read the worked answer
Technical fix: derive the authenticated user's identity from the session or token and check authorization server-side on every request; do not accept an arbitrary student ID from the URL. Use an opaque record reference or a server-side lookup scoped to the user. Add role-based access for counselors and administrators, audit logging of every record access, and alerting on rapid sequential ID changes. Verify with two test accounts: student A must receive 403 or 404 for student B's record, and a counselor with a legitimate relationship must succeed. Add input validation and automated authorization tests. Disclosure process: the teacher escorts the student to the designated security contact, documents the report, confirms no retaliation for a good-faith report if policy allows, and sets a communication timeline. The student should not post details or contact the press before the school has a chance to fix the issue.