Secure online quizzes: why the answer key should never reach the browser

A web page is code that runs on the learner's own computer. To show a quiz, the page asks a server for the questions. The simplest way to build a quiz is to ask for everything at once: the questions, the options, and a flag on each option saying whether it is correct. The page then shows the questions, waits for clicks, and compares the clicks against those flags to give an instant score.

It works, and it feels fast. The problem is that the flags were delivered to the learner's computer before the quiz started. Every modern browser ships with developer tools, and the Network tab shows each response the page received in plain text. A curious learner can open it, find the quiz response, and read which option is marked correct. No hacking skill is needed, only a search for a word like "correct".

This is a design pattern, not one product's bug. It appears in course tools, form builders and home-built quizzes alike, because instant client-side grading is the easiest thing to build. That is why it is worth checking, whatever you use.

You can test any quiz you run in about five minutes, and you should do it as a learner, not as an admin, because admin views often load answers on purpose. Create a test learner account, enroll it in a course with a quiz, and open the quiz in a desktop browser.

Before answering anything, open the developer tools (right-click, Inspect, then the Network tab) and reload the page. Look through the responses for the quiz content and search them for words like correct, answer, is_correct or solution. If you find the right answers marked before you have submitted, your quiz leaks. If you only find the question text and options, check again after you submit; seeing explanations then is normal and fine.

Write down what you find. If the quiz is low stakes, a practice check for your own learners, a leak may not matter. If the quiz decides a certificate, a grade or access to the next module, it does.

Most common anti-cheating tricks act on what the learner sees, not on what the browser received. A countdown timer limits time but the key is still there. Shuffling options changes their order on screen, but a flag that travels with each option moves with it. Disabling right-click or copy and paste blocks the casual shortcut, not the developer tools menu or a keyboard shortcut.

Obscuring the data, for example by encoding it, slows down a determined learner by minutes. If the browser can decode the answer key to grade the quiz, so can the person using the browser. The only durable fix is for the browser never to receive the key in the first place.

In a server-graded quiz the flow splits in two. When the learner starts, the server sends a sanitized copy of the quiz: question text and options, with no correct flags and no explanations. The learner answers. When they submit, the browser sends only their choices back. The server compares them with the key it never shared, records the score, and only then returns the result and any explanations.

Question types that are harder to hide need extra care. In an ordering question, if the items arrive in the correct order and the page shuffles them, the original order is the answer. In a matching question, if each pair shares an identifier, the identifiers give it away. A properly sanitized quiz sends these with opaque keys and an order that carries no information.

The cost of server grading is a short round trip on submit instead of an instant score, which learners rarely notice. The benefit is that the score in your records reflects what the learner knew.

If a quiz result changes anything that matters to someone outside the course, such as a certificate, a grade, a promotion or a compliance record, grade it on the server. If it is a self-check that only helps the learner, browser grading is acceptable and instant feedback may even help.

Server grading protects the answer key. It does not stop a learner from asking a friend or searching the web during an open-book quiz. Pair it with question banks, so different learners see different questions, and with applied work for anything high stakes.

It also helps to decide what learners see after submitting. Showing the correct answer and an explanation straight away is good teaching, but if retakes are allowed and the same questions come back, it turns the first attempt into a free look at the key. Either draw new questions per attempt, limit retakes, or hold explanations until the final attempt.

HiveLearn grades quizzes on the server. When a learner starts an attempt, they receive the questions without the answer key; matching and ordering questions use opaque keys so the correct answer cannot be inferred from the data. Their answers are graded server-side on submit, and explanations and the correct answers are returned only after that, for the results screen.

All six question types work this way: multiple choice, multi-select, true/false, fill in the blank (not case sensitive), ordering and matching. Quizzes can draw from question banks so each attempt gets a different set, and a lesson can require learners to pass its quiz before they continue.

Instructors and editors viewing a quiz in the course see the full answer key, because they need to. That is the reason to run the five-minute test above as a learner account, on any platform.

Quizzes are one part of the course tools, which sit alongside community, events and payments in one place. See the pricing page for which plan includes them.