Overview

While practicing basic web-security concepts, I explored the registration flow of a Saudi cybersecurity learning platform restricted to university students only. The system requires a verified .edu.sa university email before giving users access to student-only content.

However, during testing, I discovered a logical flaw that allowed the full bypass of university email validation using any external email provider, including Gmail.

None

How the Registration Flow Is Supposed to Work

According to the intended logic, the registration should follow these steps:

Select University

Verify University Email

Complete Registration

The frontend enforces a format similar to:

username@students.university.edu.sa

Any deviation triggers a visible error and prevents the user from moving to the next step.

The question was: Does the backend enforce the same constraints?

The answer turned out to be no.

None
الفرحه

Frontend vs Backend Behavior

On the frontend:

  • Email input is restricted
  • Only university domains appear valid
  • Non-edu.sa emails are blocked visually

But once the request is intercepted using a proxy tool, the reality becomes clear:

  • The email is sent inside a JSON body
  • Changing it to any email address still triggers an OTP
  • The backend accepts any domain
  • The account completes registration normally
  • Student privileges are assigned immediately
None
This screenshot shows the intercepted request being modified to use a non-university email address.

Despite that, the backend responds successfully and sends the OTP.

None
None
This screenshot shows the frontend properly rejecting Gmail and forcing a university pattern. This highlights the mismatch: the client enforces the rule visually, but the backend does not.

Root Cause Analysis

This vulnerability is a pure Business Logic flaw.

Technical causes include:

  1. Missing server-side domain validation
  2. No comparison between selected university and email domain
  3. OTP endpoint accepts any email
  4. Role assignment happens before verification
  5. Backend trusts client-side logic

This type of design flaw does not require payloads or injections. It results entirely from misplaced trust in the client.

Impact

The issue allows:

  • Unauthorized users to register as students
  • Free access to student-only learning materials
  • Invalid entries in statistics and activity logs
  • Exploitation of resources intended for verified university students
  • The inability to distinguish real students from outsiders

Recommendations

To properly secure the workflow:

  1. Enforce server-side domain validation
  2. Maintain a whitelist of approved .edu.sa domains
  3. Reject OTP requests for invalid domains
  4. Assign roles only after verified email confirmation
  5. Add monitoring and alerts for abnormal registration attempts

Takeaways

Key points for learners:

  • Client-side validation is not a security control
  • Business logic flaws often bypass entire security models
  • Identity and domain verification must be handled server-side
  • Intercepting requests can reveal major inconsistencies in workflow design

Acknowledgment This research was conducted together with my friend and research partner Cyber Man, who worked with me step-by-step during the analysis and testing of this vulnerability. I appreciate his collaboration and valuable input throughout the process.

Closing Thoughts

This case demonstrates how a small oversight in backend validation can break an entire verification pipeline. Even well-designed educational platforms can suffer from issues when core logic is not strictly enforced.