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

Five Common Security Mistakes in Online Marking Portals — Explained in Plain Language

A recent public report described five common security mistakes found in an online marking portal. CBSE has stated that the affected site was a development server, not their production system. Either way, these are real-world mistakes worth understanding — here's what each one means, and how a properly built platform prevents them.

Five Common Security Mistakes in Online Marking Portals — Explained in Plain Language

What This Post Is About

In May 2026, an independent researcher published a public report describing five security problems they said they had found in an online marking website connected with CBSE. (The original report is here.)

An important note on context: CBSE has officially stated that the website in the researcher's report was a *development* environment — a test website used internally — and not the actual production system used to evaluate students' answer sheets. We cannot independently verify either side of that, and we are not going to make claims about what is or is not true on CBSE's live system.

What we *can* do — and what is genuinely useful — is treat the five problems described in the report as a real-world example of the kinds of mistakes that any online marking platform must avoid, whether on a development server or a production one. These are well-known categories of security mistake. Discussing them openly helps institutions ask better questions when they choose a platform.

This post is written for evaluators, moderators, controllers of examinations, and college administrators — not for software engineers. We'll explain each of the five problems using everyday examples, and then show how a properly built platform like MAPLES OSM is designed to prevent each one — on every environment we run, development and production alike.

Problem 1: The Master Key Was Left in Plain Sight

What the report described: A master password — a kind of universal key that worked on any account — was written directly into the code that the website sends to every visitor's browser. Anyone who knew where to look could find it in seconds.

A simpler way to picture it: Imagine a college where the principal's master key opens every classroom and every office. Now imagine that the principal taped a photocopy of that key to the front gate, where any visitor could photograph it on their way in. That is essentially what happened. The "key" was not hidden anywhere — it was shipped to every person who visited the website.

Why it is dangerous: Once someone has the master key, the system has no way to tell them apart from a real evaluator, moderator, or administrator. They can sign in as anyone they want.

How MAPLES OSM is built differently:

  • No master key of any kind is ever sent to the browser
  • The keys and passwords that the system uses internally stay on our protected servers — they never travel out to anyone's computer
  • To log in, an evaluator needs their own User ID *and* a one-time password (OTP) that is sent to their registered phone, just like an Aadhaar OTP or a bank OTP
  • An attacker who somehow got hold of a User ID still cannot log in without the phone the OTP is sent to

    • Problem 2: The Answer Key Was Handed to the Person Being Tested

    What the report described: When a user typed in their OTP, the system sent that OTP back to the user's computer first, and the user's computer then compared what was typed against what was received. The "correct answer" was visible to anyone watching the network traffic.

    A simpler way to picture it: Imagine an exam where the invigilator hands every student the answer key first, then asks the student to compare their own answers against it and mark themselves. Of course every student will say they got everything right — because they can see the answers.

    That is the kind of design the report described. The website was said to give the OTP to the user's computer, and then trust the computer to honestly say whether the right OTP was typed — which would make the entire OTP step meaningless if true.

    Why it is dangerous: OTP exists to prove that the person logging in actually has the registered phone. If the OTP is sent to the computer instead of just the phone, that proof is destroyed.

    How MAPLES OSM is built differently:

  • The OTP is generated on our server, sent to the evaluator's registered phone via SMS, and the value itself is never sent to the browser
  • When the evaluator types the OTP, only what they typed is sent back to our server, which then compares it against what was originally generated
  • The system only ever replies with "correct" or "incorrect" — it never reveals the OTP
  • After a small number of wrong attempts, the OTP is cancelled and a new one must be requested
  • Every attempt — correct or incorrect — is recorded with the time, the IP address, and which device was used

    • Problem 3: The Exam Hall Doors Were Left Unguarded

    What the report described: The pages that evaluators use — dashboards, profile screens, mark-entry screens — were not protected on the server side. If someone typed the right web address directly into their browser, the system simply opened the page without checking whether they were actually logged in.

    A simpler way to picture it: Imagine an exam hall where the only person checking IDs sits at the main gate of the campus. Once you are past the gate, every classroom is unlocked. Someone who jumps over the fence and walks straight to a classroom is treated like a legitimate student — because nobody at the classroom door bothered to check.

    The report described the same problem on the website it examined: the "front gate" (the login page) was checking IDs, but the actual mark-entry rooms had no one at the door.

    Why it is dangerous: Anyone who could guess or look up the web address of a sensitive page could simply visit it directly. The login page existed, but it was not actually protecting anything.

    How MAPLES OSM is built differently:

  • Every single screen and every single action — viewing an answer book, entering marks, approving moderation — is checked on our server before anything is shown
  • The check is done at the level that matters: the server. Even if someone tries to skip the login page and go directly to a sensitive screen, the server refuses to show it without a valid, logged-in session
  • An evaluator's session can only do evaluator things. A moderator's session can only do moderator things. The roles are enforced behind the scenes, not just by hiding menu items

    • Problem 4: Anyone Could Change Anyone's Password Without Knowing the Old One

    What the report described: The system that changed passwords did not ask for the current password. It accepted only a user's ID and a new password, then simply changed it. There was no proof that the request came from the actual account owner.

    A simpler way to picture it: Imagine going to a bank and saying "I want to change the locker code for locker number 47." A safe bank will ask you to prove you own that locker — your ID, the old code, perhaps a signature. The website in the report did neither, according to the researcher. It would have changed locker 47's code based on nothing more than knowing the locker number existed.

    If that description is accurate, it would mean an attacker who knew someone's User ID could lock that person out of their own account by setting a new password — and then walk in as them.

    Why it is dangerous: A password change is one of the most sensitive actions a system can perform. Doing it without verification turns the password from a lock into a sticker that anyone can replace.

    How MAPLES OSM is built differently:

  • Evaluators and moderators cannot change their own passwords through some general web form — that whole risky pathway does not exist on our platform
  • When a password reset is genuinely needed, it is done by an administrator from a dedicated dashboard, with the administrator's role and identity verified at every step
  • The administrator's action is permanently recorded: who reset whose password, at what time, from which device. If anything ever looks suspicious, the trail is there
  • The user being reset is identified by the administrator's dashboard, not by anything the browser claims — so attackers cannot trick the system by sending fake user IDs

    • Problem 5: The System Believed Whatever the Browser Said About Who You Were

    What the report described: Throughout the portal, nearly every action took a user's ID from the browser's request and trusted it without checking. So if a logged-in attacker simply changed the user ID in their browser request from their own to someone else's, the system would carry out the action *as that other person*.

    A simpler way to picture it: Imagine an exam centre that gives every evaluator a name badge. Now imagine that the evaluator is allowed to write any name on the badge themselves, and the staff at every desk just reads what is written on the badge without checking ID. An evaluator could sign in as themselves, then write the chief examiner's name on the badge, and from that point on the entire centre would treat them as the chief examiner.

    This is what the website in the report was described as doing — reading the name off the badge instead of checking ID at every desk.

    Why it is dangerous: This is the deepest problem of the five, because it means the system never really knew who anyone was. The other problems were individual mistakes; this one was the foundation being wrong.

    How MAPLES OSM is built differently:

  • When you log in, our server creates a sealed identity record that the browser cannot edit
  • Every time you do anything — open an answer book, enter a mark, submit moderation — our server checks the sealed record, not whatever the browser claims
  • If your browser says "I am user 12345" but the sealed record says you are user 67890, the server trusts the sealed record and ignores the browser
  • This means it is structurally impossible to act as someone else simply by editing a browser request, which is the technique the researcher described

    • The New Threat: Even Untrained People Can Now Run These Attacks

    Until very recently, finding the five problems above required an experienced security researcher who knew how to read code and reverse-engineer websites. That kind of work used to take days or weeks.

    In April 2026, the UK government's AI Safety Institute and an independent group called METR tested the newest Anthropic AI model — known as Claude Mythos — and found that it could:

  • Independently solve expert-level cybersecurity puzzles 73% of the time
  • Complete a 32-step simulated network attack on its own
  • Work autonomously for 16 hours on a single task without needing a human to guide it

    • What this means in everyday terms: the kind of attacker who, two years ago, needed a skilled team and a week of effort can now potentially get the same result by typing a single instruction to an AI system. The "barrier to entry" for attacking exam-evaluation platforms has dropped dramatically.

    This is why a platform that holds something as sensitive as student exam marks must be built assuming that automated attackers are constantly probing it.

    What We Do to Stay Ahead of This

  • We assume from day one that an attacker has unlimited automated tools to scan and probe our platform — and we build our defences to remain effective even under that assumption
  • All the protections described above (server-side checks on every action, no master keys, sealed identity, secure password handling) work regardless of how clever or automated the attacker is
  • Every login, every password reset, every mark entry, and every administrative action is permanently logged in a way that cannot be quietly erased. If anything ever goes wrong, the trail is there to investigate
  • We watch for unusual patterns — like an evaluator suddenly logging in from a different city, or attempting to edit marks at an unusual speed — and require additional verification when something looks off

    • How Cloudflare Protects the Front Door

    Before any visitor reaches the MAPLES OSM application at all, their request passes through a service called Cloudflare — one of the world's largest internet protection networks. Cloudflare sits like a security guard in front of our entire platform.

    Here is what that guard does for us:

  • Stops floods of fake traffic. If thousands of automated bots try to overwhelm the platform during a busy evaluation period, Cloudflare absorbs the attack at the edge of the internet, so our actual evaluators never notice
  • Blocks known attack patterns. Cloudflare keeps an up-to-date list of attack patterns used by hackers worldwide. Any request matching one of these patterns is rejected before it ever reaches us
  • Limits how fast anyone can knock on the door. A normal evaluator might try to log in once or twice. An attacker tries thousands of times per minute. Cloudflare cuts off anyone who tries too many times — automatically
  • Restricts access to approved networks per institution. When a university or examination board gives us a list of approved IP addresses (the network locations of their evaluation centres), we configure Cloudflare so that the platform can only be reached from those locations. Evaluators trying to log in from random homes, internet cafés, or unknown networks are blocked before they can even attempt
  • Encrypts every connection. All traffic between an evaluator's computer and our servers is scrambled in transit, so nobody listening in on the network can read it

    • The result: a request that wants to attack our platform has to first get past a globally distributed security network, then past our application-level protections, and then past our role-based checks. It is layers of defence, not a single wall.

    What This Means When You Are Choosing a Platform

    If you are part of a university, board, or institution evaluating online marking software, here are simple questions to ask any vendor — and what the right answers sound like:

  • "If I open the website's code, can I find any passwords or keys?" The correct answer is *No, nothing sensitive is sent to the browser*. If they hesitate, that's a warning sign.
  • "Where is the OTP checked — on my computer or on your server?" The correct answer is *Only on our server*. There is no other safe answer.
  • "What stops someone from typing a sensitive page address and just visiting it?" The correct answer is *Every page is checked on our server before it loads. The login page is not the only protection*.
  • "Can someone change someone else's password by changing a number in a web request?" The correct answer is *No, the user is identified from our server's records, not from anything sent by the browser*.
  • "What happens if someone tries to attack the platform with automated tools?" The correct answer should mention an edge protection service like Cloudflare, rate limiting, and audit logs.
  • "Can my institution restrict access to only our examination centres?" The correct answer is *Yes, we can allow only your approved network locations and block everyone else*.
  • "What do you keep a permanent record of?" The correct answer is *Every login, every mark entry, every password reset, every administrative action — with the time, the IP address, and the device*.

    • In Summary

    The researcher in the public report did not need expensive tools or insider information — they described looking at the website's code, finding a master password, watching the OTP being sent back to the browser, and testing a few simple tricks. Whether the website was a development server (as CBSE has stated) or something else, the broader point stands: these are the basic protections that an exam-grading system must have on *every* environment, internal or public.

    MAPLES OSM is built on that philosophy:

  • No secrets in the browser — nothing sensitive is ever sent to anyone's computer
  • Every action checked on the server — the browser is never trusted to enforce rules
  • Sealed identity — once you log in, your identity cannot be edited by the browser
  • Restricted password resets — only administrators can reset, and every reset is logged
  • Cloudflare at the front door — floods, bots, and known attacks are stopped before they reach us
  • Optional per-institution network restrictions — only your evaluation centres can access the platform
  • Complete audit trail — every action is permanently recorded for review

    • Exam evaluation is one of the most consequential things a college or board does. The platform that holds those marks has to be built like a vault, not like a marketing website.

    Further Reading

  • The Five Things to Get Right Before Launching Digital Evaluation — What CBSE's rollout problems taught us
  • RTI Compliance and Audit Trails in Exam Evaluation — Why a permanent record matters
  • Evaluator Anonymity in Digital Marking — Keeping the evaluator's identity safe

    • Ready to digitize your evaluation process?

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

    Request a DemoView Features