Discovering a Security Flaw in a Government Portal Used by 3 Lakh+ Students

A few weeks ago, while interacting with the Bihar State Education Finance Corporation (BSEFCL) portal, I came across something that seemed unusual.

At first glance, it appeared to be a minor frontend behavior issue. However, after investigating further, I discovered a Broken Access Control vulnerability that could potentially expose sensitive beneficiary information(like full address and details of bank transactions used to provide monetary benefits) to unauthorized users.

The issue has since been responsibly disclosed, validated by CERT-In, and fixed by the concerned authorities. With the vulnerability now fixed, I wanted to document the technical and professional lessons from the experience.

Website: https://www.bsefcl.bihar.gov.in/

Some Context:

The government portal is used by beneficiaries of various educational assistance schemes and contains application-related information for registered students.

While using the portal as a legitimate user, I noticed certain functionality appeared to be conditionally displayed based on information stored within the browser.

So, it made me think:

Is authorization actually being enforced on the server, or is the frontend simply hiding functionality?

This is how I came across this vulnerability.

Discovery of the Vulnerability:

One of the most common mistakes in web security is trusting the data received from frontend. Developers often hide buttons, pages and menus from unauthorized users and assume that those users can no longer access the underlying functionality.

But, they forget that browsers are completely under user control, may it be session storage, local storage, cookies or client-side JS. They should be considered untrusted.

After performing limited testing on my normal student account, I discovered that the functionality intended for privileged users could become accessible through manipulation of client-controlled state.

After I updated the specific key on the client-controlled state(i.e. session storage) of the website, I supposedly had the "SuperAdmin" access to the website (it said so on the logged in dashboard after a refresh). Now, I was able to see a new button on the website that took me to a page which allowed me to search for details of any beneficiary of the portal using merely their registration ID which in this case was a simple number with a few digits. At this point, I thought:

Only the frontend interface is visible. They must have setup backend validation for the API which actually returns the sensitive details.

Unfortunately, there were no authorization checks for authenticated users i.e. even if I was a general student beneficiary, I was able to search and fetch the details of every other beneficiary.

This transformed what initially looked like a frontend issue into a serious access control vulnerability.

Understanding the Root Cause

The underlying problem was a lack of proper server-side authorization enforcement. The frontend decided which functionality should be available to different users and the backend didn't verify whether the authenticated user actually had the permissions required to access the requested data.

In secure systems:

1. Authentication determines who you are.
2. Authorization determines what you're allowed to access.

Even when the frontend controls are bypassed, the backend should always validate permissions independently. In this case, it did not and was a classic example of Broken Access Control.

Importance:

A vulnerability does not always need remote code execution to be dangerous. If unauthorized users can access restricted information, there may still be significant impact.

The affected data related to beneficiaries of a government portal and scheme. It included sensitive information like full address and bank transaction details of monetary benefits availed by the beneficiary.

Because of the sensitive nature of the information involved, I intentionally limited my testing to verifying the existence and impact of the issue. I did not perform bulk data extraction, automated enumeration, destructive testing, data modification and privilege escalation beyond what was necessary to confirm the vulnerability.

Lessons For Developers:

1. Client-side controls are not security controls and they should be used improve user experience, not enforce security boundaries independently.
2. Authorization must always be server-side. Never assume that because a user can't see a button, they can't access the functionality behind it.
3. Broken access control is often simple and are a result of basic authorization oversight.

Final Thoughts:

This was my first experience taking a vulnerability through a complete responsible disclosure lifecycle. From discovery to reporting, validation, and remediation, good experience I'd say.

Security is not just about finding flaws. It is about helping make systems safer while protecting users throughout the process. I am grateful to the CERT-In team and the concerned authorities for reviewing the report and addressing the issue.

Hopefully this write-up encourages more people to learn about secure design, responsible disclosure, and the importance of proper access control.

Thanks for reading.

— Prince Raj https://theprinceraj.tech