MAPLES OSMAll Posts
Security2026-05-26·10 min read

What a Secure On-Screen Marking Platform Looks Like: Lessons from CBSE OSM's Disclosed Vulnerabilities

A security researcher recently disclosed five critical flaws in CBSE's On-Screen Marking portal — hardcoded passwords, client-side OTP checks, missing route guards, IDOR. Here's what each flaw means, and the architectural choices that prevent them in a properly built OSM.

What a Secure On-Screen Marking Platform Looks Like: Lessons from CBSE OSM's Disclosed Vulnerabilities

A Public Disclosure That Every OSM Buyer Should Read

In May 2026, an independent security researcher published a write-up titled *Hacking CBSE* detailing five distinct vulnerabilities found in the Central Board of Secondary Education's On-Screen Marking (OSM) portal — the system used to evaluate Class 12 board exams for over 18.5 lakh students. (Original disclosure)

The findings were not theoretical. The researcher demonstrated full account takeover and the ability to navigate evaluator dashboards using credentials extracted from a publicly-served JavaScript bundle. Mark editing — the integrity-critical action OSM exists to protect — was reachable.

This post is not about CBSE. It is about a category of mistakes that any institution procuring an OSM platform should know how to recognize, and the architectural choices a well-built OSM makes to avoid each one. We'll walk through the five disclosed flaws and contrast them with how MAPLES OSM is designed.

Flaw 1: Hardcoded Master Password in the JavaScript Bundle

What was disclosed: A plaintext master password was embedded in the OSM portal's client-side JavaScript. Anyone who opened browser DevTools could read it. Combined with a target's user ID and school code, it bypassed the entire authentication flow.

Why this happens: It is the easiest possible shortcut for a development team under deadline pressure. A "debug" or "support" backdoor gets added for internal testing and never removed. The JavaScript bundle is treated as if it were server-side code — but anything shipped to the browser is public.

The architectural rule that prevents it: *No secret of any kind belongs in client-side code.* Not a password, not an API key, not a signing secret, not a "support override." If the browser receives it, attackers receive it.

How MAPLES OSM handles authentication:

  • Login requires a short-lived OTP delivered out-of-band (SMS via a dedicated gateway), verified server-side before any session is issued
  • No credentials of any kind are embedded in client-side code; all secrets sit on the server with restricted access
  • Passwords, where used, are stored using a slow, salted hash — never reversible, never logged
  • Session tokens are signed with a server-side secret that never leaves the server

    • Flaw 2: Client-Side OTP Validation

    What was disclosed: The CBSE portal's server returned the OTP itself inside the authentication response. The browser then compared what the user typed against the OTP it had received. The "secret" was visible in the network tab.

    Why this is catastrophic: OTP exists to prove possession of a second channel (a phone, an email inbox). If the OTP is sent to the browser, the second-channel assumption is gone — the browser is the channel. Anyone watching the network response holds the OTP.

    The architectural rule: *Secrets are verified on the server. The client never receives the answer key.* The browser sends the user's input; the server compares it against its own stored value and replies only with success or failure.

    How MAPLES OSM handles it:

  • OTP is generated and stored server-side with a short time-to-live; the value itself is never returned to the browser
  • Authentication responses carry only the outcome — success returns a session, failure returns a generic error
  • Each failed attempt is counted, with limits that cause the OTP to be invalidated after a small number of tries
  • Every attempt — successful or failed — is written to the audit log with timestamp, IP address, and user agent

    • Flaw 3: Missing Route Guards

    What was disclosed: The CBSE portal is built in Angular. Sensitive routes — /dashboard, /profile, /evalscriptsview — had no canActivate guards. By writing fake values into browser local storage and navigating directly, the researcher could load evaluator screens without ever authenticating.

    Why this is a misunderstanding of how web security works: A client-side route guard is not a security boundary. Even with guards, a determined attacker can patch the JavaScript. The real boundary is the API. Every API call must independently verify the session — the UI cannot be trusted to gatekeep anything.

    The architectural rule: *The browser is hostile territory. Authorization belongs on every server-side endpoint, not on the page transition.*

    How MAPLES OSM handles it:

  • Every privileged API endpoint validates the session token server-side before any business logic runs
  • The session resolves to an authenticated user record on the server — the client never asserts who it is
  • Role-based access control is enforced at the API layer; an evaluator session simply cannot reach moderator or admin actions
  • The frontend route guards exist for UX (showing the right screen), but they are not what protects the data

    • Flaw 4: Password Change Without Verifying the Current Password

    What was disclosed: The CBSE password-change API accepted a new password and a user ID — nothing else. It never asked for the current password and never verified that the request came from the legitimate session owner.

    Why this is dangerous in combination: This flaw alone allowed permanent account takeover. Combined with flaw 5 (trusting client-supplied user IDs), an attacker could change the password of *any* user on the system.

    The architectural rule: *Identity-changing actions require re-authentication. Always.*

    How MAPLES OSM handles it:

  • There is no self-service password-change endpoint exposed to evaluators or moderators — the attack surface that this flaw exploited simply does not exist on our platform
  • Credential resets are performed only by administrators, from a dedicated administrative dashboard gated by role-based authorization
  • The target user for any reset is identified server-side; client-supplied identifiers are validated against the administrator's permissions before any change is written
  • Every reset writes an audit log entry capturing the administrator, the target user, timestamp, IP, and user agent — administrators can review the full trail at any time

    • Flaw 5: Systemic IDOR — Trusting Client-Supplied User IDs

    What was disclosed: Across "practically every POST request," the CBSE backend used a user ID that the client sent in the request body. This is an Insecure Direct Object Reference (IDOR) pattern. Change the ID in the request, act as anyone.

    Why this is the deepest flaw: The other four are individual coding mistakes. This one is architectural. It says the backend was built without a clear model of "who is this request actually from?" — the system trusted the browser to tell the truth.

    The architectural rule: *The identity of the caller is established by the server from the session, never by anything the client sends. User-supplied IDs are treated as untrusted parameters and authorized against the session identity on every call.*

    How MAPLES OSM handles it:

  • A shared authentication layer resolves the session to a server-side user record before any handler executes
  • Every handler operates on this resolved identity; client-supplied user IDs are treated as untrusted parameters and authorized against the session before any read or write
  • Authorization questions ("is this user permitted to act on this answer book?") are answered against the resolved identity, not against URL parameters or request bodies
  • Data queries are scoped to the user's institution and role at the database layer, making cross-tenant access fail by default

    • The New Threat: Autonomous AI Agents Can Now Execute These Attacks at Scale

    The CBSE disclosure was the work of a single researcher who manually inspected JavaScript bundles and reasoned through the authentication flow. That kind of analysis used to take weeks. As of April 2026, it takes minutes.

    Anthropic's Claude Mythos model — evaluated publicly by the UK AI Safety Institute and METR earlier this year — demonstrated the ability to autonomously complete 16-hour engineering tasks without human supervision, scored 73% on expert-level capture-the-flag security challenges, and became the first model to successfully execute "The Last Ones," a 32-step corporate network takeover simulation, from start to finish.

    What this means in practice for OSM platforms:

  • Vulnerability discovery is now automated. What took a human researcher days of reverse engineering, an AI agent now does in an afternoon — across hundreds of targets in parallel.
  • Exploit chaining is now automated. The five CBSE flaws had to be discovered and stitched together by a human. An autonomous agent can now do this end-to-end, with no human in the loop after the prompt.
  • The cost of attack collapsed. A determined attacker no longer needs a security team. They need an API key.

    • This raises the bar for every platform that holds high-integrity data — and OSM platforms hold some of the highest-integrity data in the education system. "Security by obscurity" or "nobody will bother attacking us" was never a real defense; in mid-2026, it is actively dangerous.

    How MAPLES OSM Mitigates the Autonomous-Agent Threat Model

    We assume from the start that an attacker has unlimited automated reconnaissance capability. Our defenses are designed to fail safely even when an attacker knows everything about the system except its server-side state:

  • No client-shipped secrets — no value in scraping our bundles, because nothing actionable is there
  • Per-endpoint authorization derived from session — pattern-matched IDOR scans return nothing useful
  • Defensive rate limiting on every authentication and mark-editing endpoint — automated credential stuffing and parameter fuzzing are throttled and flagged
  • Anomaly detection on evaluator behavior — sudden geographic shifts, abnormal mark-edit velocity, or session reuse from new devices trigger step-up authentication
  • Tamper-evident audit logs — every action is signed and stored such that retroactive editing is detectable; an attacker who gets in cannot quietly erase their trail
  • Pre-deployment AI-assisted code review — we run our own automated security analysis (including LLM-based static analysis) on every release, catching the same patterns an attacker's tooling would find

    • Cloudflare: Our Perimeter Defense Against Automated Attacks

    MAPLES OSM sits behind Cloudflare for every customer-facing surface — the public site, the evaluator portal, and the administrative APIs. This is not branding; it is a deliberate architectural choice for a specific threat model.

    What Cloudflare gives us in front of the application:

  • DDoS mitigation at the edge — volumetric attacks (L3/L4) and application-layer floods (L7) are absorbed before they reach our origin, keeping the platform available during peak evaluation windows when downtime would be catastrophic
  • Bot management — automated tools that probe for IDOR, credential stuffing, or vulnerability scanning are fingerprinted and challenged at the edge; the request never touches our application code
  • Web Application Firewall (WAF) — managed rule sets block known exploit patterns (SQL injection, XSS, deserialization attacks) and we add custom rules for OSM-specific abuse patterns
  • Rate limiting at the edge — per-IP and per-session limits on authentication endpoints, OTP generation, and password-change APIs, applied before requests reach our servers
  • TLS termination with modern cipher suites only — TLS 1.3, automatic certificate management, and HSTS preload, eliminating an entire class of downgrade and MITM concerns
  • IP allow-listing per institution — when a university or board provides a list of evaluation-centre IP ranges, we enforce those at the Cloudflare edge so that evaluator and administrator access is only possible from approved networks; requests from anywhere else are blocked before they reach the application
  • Geographic and ASN-based access controls — administrative interfaces can be further restricted by country or network origin where customer policy requires it
  • Always-on logging and analytics — every request is logged at the edge, giving us a tamper-resistant view of traffic patterns independent of our application logs

    • The practical effect: even before a request reaches the MAPLES OSM application, it has already been filtered, rate-limited, and fingerprinted. The autonomous attacker described above does not get to scan our endpoints at will — most of their reconnaissance traffic is dropped or challenged at the edge, and what remains is logged for review.

    This layered approach — Cloudflare at the edge, hardened application architecture behind it, and immutable audit trails throughout — is how a modern OSM platform should be deployed. Any one layer can be bypassed by a sufficiently capable attacker; the combination is what makes the platform safe at scale.

    What This Means for Institutions Choosing an OSM Platform

    When the integrity of board examinations rests on a software platform, "the vendor passed UAT" is not enough. UAT confirms that features work — it does not catch missing route guards, hardcoded credentials in bundles, or IDOR patterns. Those require a different kind of review.

    If you are evaluating OSM vendors, ask the following:

  • Has the platform undergone independent security testing? Ask for the report. A vendor that has never been tested is not a vendor that has passed.
  • What does the authentication flow look like end-to-end? Specifically: where is the OTP verified, and what does the success response contain?
  • How is the user's identity determined on each API call? The correct answer is "from a server-side session." Any other answer is a red flag.
  • What is the audit trail policy for credential changes? A platform without immutable logs for sensitive actions cannot prove integrity after the fact.
  • What happens when an evaluator's session expires? A platform that silently extends sessions on the client is not enforcing them on the server.
  • Is there an edge protection layer (WAF, bot management, rate limiting) in front of the application? A platform exposed directly to the internet, without an edge defense, is unprepared for the autonomous-agent era.
  • What is the platform's response plan when an AI-driven attack pattern is detected? Real platforms have answers to this. Wishful ones do not.

    • How MAPLES OSM Approaches Security as Architecture

    Security in OSM is not a checklist of features added at the end. It is a set of architectural choices made before the first line of code — about where identity lives, what the browser is trusted with, and how every action is logged.

    Our platform is built on these principles:

  • Server-side session resolution on every request — the browser cannot claim an identity it does not have
  • OTP and credentials verified server-side only — no secrets shipped to the browser, ever
  • Role-based access control enforced at the API layer — UI restrictions are convenience, not security
  • Immutable audit logs for every evaluation action, credential change, and administrative event
  • Independent penetration testing before every major release, with findings tracked to resolution
  • Cloudflare edge defense — WAF, bot management, DDoS mitigation, and rate limiting in front of every customer-facing endpoint
  • Designed for an autonomous-agent threat model — defenses assume the attacker has unlimited automated reconnaissance, and remain effective anyway

    • The disclosure about CBSE's portal is a reminder that OSM is not a UI-with-a-database. It is a high-integrity workflow system that holds career-defining outcomes for millions of students. The architecture has to match the stakes.

    Further Reading

  • The Five Things to Get Right Before Launching Digital Evaluation — What CBSE's operational rollout problems taught us
  • RTI Compliance and Audit Trails in Exam Evaluation — Why immutable logs matter
  • Evaluator Anonymity in Digital Marking — Identity, separation, and bias control

    • Ready to digitize your evaluation process?

    See how MAPLES OSM can transform exam evaluation at your institution.

    Request a DemoView Features