Online assessment platform integrity depends on what your server controls, not on what the browser is told to block. Question sets issued by the server, per-student randomisation, server-side timing and answer-pattern checks hold up under pressure. Fullscreen locks, copy-paste blocking and tab-switch alerts mostly don't.
Maybe a university partner, a certification body or your own board has asked you a direct question: how do we stop cheating? You have a lockdown ticket in the backlog, a proctoring vendor's deck in your inbox and limited engineering time. This article is about where that time should go.
Why can a student get around browser lockdowns?
The browser runs on the student's machine, and the student controls that machine. Anyone can read, pause or override a check written in JavaScript by opening developer tools, installing an extension or running the exam inside a virtual machine.
Tab-switch detection is the clearest example. It listens for focus and visibility events. A phone on the desk, a second laptop or a friend on a call never fires those events. So the control catches the student who opened another tab by accident and misses the one who planned ahead.
Copy-paste blocking works the same way. It stops casual copying and does nothing against a phone camera.
The bigger leak usually isn't about lockdown at all. It's the API response. Many platforms load the whole test into the page at the start, including correct answers or scoring keys, so the front end can grade instantly. Anyone who opens the network tab has the answer key. No lockdown fixes that.
Which anti-cheating controls actually hold?
The ones the student can't touch. If the server decides what is shown, when time runs out and what counts as suspicious, there is nothing on the student's device worth tampering with.
Server-issued question sets. The client asks for the next question and gets only that question, with no correct answer attached. The server stores the answer and grades it. Trade-off: this means more round trips, so an honest student on weak mobile data feels every slow request. You need retries and saved progress so a dropped request never loses an answer.
Per-student randomisation. Draw each question from a pool, shuffle the options and, where it makes sense, change the numbers inside the question. A shared screenshot then helps far less. Trade-off: the versions have to be equally hard, or some honest students get a harder paper by chance. Store the random seed for every attempt so you can show any student exactly what they saw when they appeal.
Server-side timing. The server records when the attempt started and rejects answers after the deadline. The countdown on screen is only a display. Trade-off: a dropped connection uses up real exam time. Set your policy in advance, for example a short grace period after reconnecting, and log every gap so support can judge cases fairly.
Answer-pattern checks. After each sitting, look for answers submitted faster than anyone could read the question. Look for groups of students who share the same unusual wrong answers, and for many attempts coming from one network or device. Shared wrong answers are a much stronger signal than shared right ones, because right answers are supposed to match. Trade-off: false positives. A flag should start a human review and never change a grade by itself.
What does weak online assessment platform integrity cost you?
A leaked answer key doesn't stay with one student. It spreads through a group chat during the first sitting, and by the second sitting the results tell you nothing. The institution voids the exam, students re-sit it, and your platform takes the blame.
The opposite mistake hurts too. Aggressive lockdowns break screen readers and other assistive tools. They also flag honest students whose browsers lose focus for ordinary reasons, like a system notification. Each false flag turns into an appeal, a support ticket and a student who no longer trusts the result.
Then there is load. With server-issued questions, every student calls your API in the same minute. If a whole cohort starts at 10:00, your integrity design is also a traffic design. Our guide to handling exam-day load on an assessment platform covers that side.
Do you need all of this?
Not always.
If your tests are practice quizzes, open-book by design or low-stakes, shuffle the options, keep answers off the client and stop there. The rest adds cost and friction, and honest students will feel it more than any cheater.
The exception is an exam in a supervised room on devices you manage. There, a locked kiosk browser such as Safe Exam Browser does work, because you control the hardware as well as the software. On a student's own laptop, lockdown is theatre. On your machines, it's a real control.
In what order should you build these controls?
Start with what leaks the most and costs the least to fix.
- Audit what the client receives. Open the network tab during a live test. If any response contains correct answers, scoring rules or the full question bank, fix that before anything else.
- Move timing to the server. If the deadline exists only in the front end, a paused script or an edited request can extend it.
- Add question pools and randomisation. Do this next if the same exam runs in more than one time slot or for more than one cohort. If one group sits it once, at one time, it can wait.
- Log events and run pattern checks. Record timing, answer changes, focus events and network data. Have a person review the flags after each sitting.
- Consider lockdown or remote proctoring last. Treat browser events as signals for review, not as verdicts. Add them only when the stakes justify the friction for honest students.
What should you ask a vendor or your own team?
These questions separate real controls from a feature list:
- What does the API return when a question loads? If the answer is in there, nothing else matters yet.
- Where is the deadline enforced? The only acceptable answer is the server.
- Can you reproduce exactly what one student saw? Without stored seeds, appeals turn into arguments.
- What happens to a student who loses connection for 90 seconds? A vague answer means honest students will lose marks.
- Who reviews a flag before it affects a grade? If nobody does, expect appeals you can't defend.
- What happens when 20,000 students press start at once? Integrity controls that fail at peak load protect nobody.
Geminate Solutions has built an exam platform with 10M+ requests per minute handled in production. That work taught one simple lesson: integrity and scale are the same design problem. Every control you move to the server adds another request at the busiest moment of the day.
If that peak worries you, read our guide to EdTech login storm architecture, or ask Geminate Solutions for a free review of your exam flow. You'll get a reply within 24 hours.
Top comments (0)