HB.

CASE STUDY / UNIVERSITY SECURITY LAB

CampusSecure

What happens when a student portal trusts the wrong user, action, or field? CampusSecure makes those checks easy to compare in a controlled lab.

PythonFlaskSQLiteAccess control
View GitHub repository

The idea

A familiar portal with a focused security question.

CampusSecure is a fictional university portal where students can view requests and edit contact details, while administrators manage announcements and approvals. The project asks whether the server checks who may access a record, perform an action, or change a sensitive field.

HOW IT WORKS

One application. Two modes.

The interface and routes stay the same. A secure mode enforces three authorization decisions; an intentionally vulnerable mode relaxes those decisions for comparison.

Secure mode

The server rejects actions outside the user’s permissions.

Vulnerable mode

Only the three documented API checks are relaxed.

THREE CONTROLLED SCENARIOS

What gets tested?

01Object access

Another student’s record

Can Alice read a request belonging to Bob?

Secure: denied · Vulnerable: record returned

02Function access

An admin-only action

Can Alice create an announcement reserved for administrators?

Secure: denied · Vulnerable: announcement saved

03Field access

A protected account field

Can Alice submit an admin role while updating her profile?

Secure: denied · Vulnerable: role changed

THE TAKEAWAY

The lesson is in the server response.

A page can hide a button or field, but that alone does not protect the underlying action. This lab compares the server response and saved data so each authorization decision is observable.

REAL LAB CAPTURES

What the lab looked like.

These images come from local, isolated lab runs. Select an image to inspect it in the gallery. Session and local network values are masked.

CampusSecure student dashboard showing Alice’s account, requests, and announcements.
Student portalThe fictional student dashboard gives the scenarios a familiar setting.
Burp Repeater capture of GET /api/requests/201 returning HTTP 200 with a record for student ID 2.
Object accessAn API request for record 201 returns another student’s fictional record in the captured vulnerable-mode run.
Burp Repeater capture of POST /api/admin/announcements returning HTTP 201 Created.
Admin-only actionThe captured API response shows an announcement being created through the admin endpoint.

SOURCE & EVIDENCE

Want the technical detail?

The repository contains the application, setup guide, scenario descriptions, and automated tests. A demonstration video has not been published for this project.