Critical Flaws in CBSE’s On‑Screen Marking Portal: How Client‑Side Logic Enabled Full Account Takeover

What was claimed

The Central Board of Secondary Education (CBSE) promotes its On‑Screen Marking (OSM) portal as a secure, modern replacement for paper‑based grading. Official statements suggest that examiner authentication relies on a three‑factor login (user ID, school code, password) followed by a one‑time password (OTP) sent to the examiner’s registered device.

What is actually new

During a casual security audit on 25 February 2026, a researcher downloaded the publicly served JavaScript bundle of the Angular‑based portal (https://cbse.onmark.co.in/cbseevalweb/main.dc17c24606b3b008.js). The bundle revealed five distinct implementation mistakes that together give an attacker full control over any examiner account.

#	Vulnerability	How it works	Impact
1	Hard‑coded master password	A literal string ("Master@CBSE2026" in the bundle) is accepted by the login routine. Supplying it skips OTP generation entirely.	Anyone with the password can log in as any examiner by providing the public user ID and school code.
2	OTP validation performed in the browser	The server returns the OTP value in the authentication response; the client script compares the user‑entered code to that value locally.	An attacker can read the OTP from the network trace or simply set the validation flag to true, bypassing the second factor.
3	No route guards on Angular routes	All internal routes (/dashboard, /profile, /evaluatordetails, etc.) lack canActivate checks. The app only redirects unauthenticated users to /login on startup.	By injecting fake tokens and role data into localStorage/sessionStorage, an unauthenticated visitor can navigate directly to any protected page.
4	Password‑change API ignores the old password	The request payload contains only ValuatorID and pin_NewPassword. The server never verifies the current password.	An attacker can reset any examiner’s password without knowing the original credential.
5	Systemic IDOR across the API	Every request reads the acting user’s ID from the client‑side eval object instead of the server‑side session.	Changing a single ID in storage lets the attacker perform any action (view scripts, edit marks, change details) as the chosen examiner.

How the bugs combine

1. Obtain a target’s user ID and school code – both are displayed on public pages or can be guessed from school listings.
2. Log in with the master password – bypasses OTP.
3. Or skip login entirely – inject a fake JWT and role into sessionStorage and navigate to /dashboard.
4. Use the unchecked password‑change endpoint to set a new password for any ValuatorID.
5. Exploit the IDOR to act as that examiner for any subsequent API call, including marking scripts.

The entire chain requires only a browser, the public JavaScript file, and a few lines of console commands. No privileged network access or reverse engineering of server binaries is needed.

Limitations and remaining questions

• Server‑side logging – The portal does log authentication attempts, but because the master password is treated as a regular credential, those logs do not flag the activity as anomalous.
• Rate limiting – The public API does not enforce request throttling on password‑reset or evaluation endpoints, making bulk abuse feasible.
• Patch status – The researcher reported the findings to CERT‑In (reference CERTIn‑XXXXX). The agency acknowledged receipt but, according to the author, has not confirmed remediation. Until the vendor updates the frontend bundle and enforces server‑side checks, the attack surface remains open.
• Scope beyond CBSE – The same OnMark platform is reportedly used by other state boards and private institutions. If the codebase is shared, the vulnerabilities may affect those deployments as well.

Takeaways for developers

1. Never place secrets in client‑side code – passwords, master keys, or OTP values must stay on the server. Even an obfuscated string can be extracted with a single request.
2. Enforce authentication and authorization on the server – Every API endpoint should derive the user’s identity from a securely signed session token, not from values the client can modify.
3. Validate all critical operations – Password changes must require the current password (or a separate, strongly authenticated flow) and must be checked server‑side.
4. Apply proper route protection – Front‑end frameworks can provide a convenient UI, but they cannot replace server‑side access control. Use canActivate guards and verify permissions on each backend request.
5. Implement rate limiting and audit trails – Detecting abnormal patterns (e.g., many password resets for different IDs) can provide early warning of exploitation.

Responsible disclosure timeline

Date	Action
25 Feb 2026	Vulnerabilities discovered during informal testing.
28 Feb 2026	Initial report sent to CERT‑In with master‑password and OTP bypass details.
03 Mar 2026	Follow‑up with video proof and additional findings (route guards, password reset, IDOR).
10 Mar 2026 – 20 May 2026	No public patch or detailed response from the responsible authority.

The author chose to wait for a reasonable remediation window before publishing the full write‑up, but the lack of visible action prompted a public disclosure to raise awareness.

---

The article is based on the author’s personal investigation and the publicly available JavaScript bundle. No privileged access to CBSE servers was used.