Security and Privacy
Assessment data is sensitive. A Next Exams installation holds answer keys, individual results, invigilator notes, and often the names and email addresses of people who are not registered users of the site. This page collects the controls that protect them.
GDPR export and erasure
Next Exams integrates with Joomla's own privacy component. A subject-access request handled through Users → Privacy includes the person's Next Exams data — attempts, responses and certificates — and an erasure request pseudonymises it.
This integration is never switched off. It belongs to the Joomla Ecosystem app alongside the article macro and Smart Search adapter, but unlike those two it ignores the app switch entirely.
The reasoning is that GDPR export and erasure are a legal obligation rather than a feature. If the privacy plugin could be disabled, Joomla's privacy component would return a silently incomplete export — which is worse than no export at all, because the operator would believe they had complied.
For the same reason the Smart Search adapter stops indexing when the app is off but never purges the existing index. An App Manager toggle must not be destructive.
Personal data in the component
| Where | What it holds |
|---|---|
| Attempts and responses | What each person answered and scored |
| Cohort rosters | Names and email addresses, including of people with no account |
| Certificates | Recipient names, exam titles, issue dates |
| Monitor log | Which invigilator acted on which attempt |
| Integrity signals | Behavioural counters per attempt |
Rosters deserve particular care because they can contain data about people who have never used your site. Viewing one requires the cohorts view permission.
The public certificate verification page is designed around this: it is keyed by a random token rather than the sequential certificate number, precisely so nobody can walk the number series and harvest recipient names and exam titles. It is also served with no-store and marked as not to be indexed.
Endpoint gating
Two properties are worth stating explicitly if you are assessing the component.
Reads are gated as strictly as writes. Listing questions exposes answer keys; listing cohorts exposes invitee emails; listing roles exposes the permission matrix. All require their view permission.
Permission declaration is structural, not remembered. Every controller must declare the feature and action it requires, and that check runs before the generic list, read, save, delete and publish operations. A controller that omits the declaration fails to load rather than defaulting to open. The pattern is deliberate: a rule the structure enforces beats a rule every new controller's author has to recall.
The same reasoning governs the public endpoints. Where an action targets a specific object — an invigilator acting on one attempt — the exam that authorises the action is re-read from the attempt rather than taken from the request, so a credential scoped to one exam cannot be used against another.
Anonymous endpoints
Some endpoints must be reachable without a Joomla login, because the people using them are guests: the exam runner, certificate download, certificate verification, LTI launches and the monitoring board.
Each authorises itself rather than relying on a session, and each is deliberately narrow:
| Endpoint | Credential |
|---|---|
| Runner | Ownership of the attempt, by user or guest token |
| Certificate download | Administrator permission, ownership, or the attempt's guest token |
| Certificate verification | None — public by design, and shows no PDF |
| LTI | The platform's signed launch token |
| Monitor | A monitoring role permission, or a redeemed grant scoped to one exam |
Invigilator grants
Grants are covered fully under Live monitoring; two properties belong here as well.
A grant is always scoped to one exam. There is no all-exams grant, because an unscoped link would expose every examinee in the system to whoever received the link.
A grant can never end an exam. Force-submit and pause are structurally excluded from what any grant can carry, so a leaked link cannot end anybody's attempt.
PINs are rate-limited per IP address, five attempts before a lockout, because six digits is only a million possibilities. Note that access codes on exams are not rate-limited — an access code is a convenience for a known audience, not a security control.
Outbound request protection
Webhooks refuse to send to loopback, private, reserved or link-local addresses, checked at send time as well as save time, and do not follow redirects. This prevents the site being used to reach services on your internal network. There is an opt-in for genuine on-premises receivers. See Webhooks.
Uploads
The media library accepts raster images only — PNG, JPEG, GIF and WebP. SVG is excluded deliberately, because an SVG can carry script. Every upload is validated by extension and by inspecting the actual image data, so a script renamed with an image extension is rejected. Uploads go to a single curated folder with a directory-listing guard.
There is no file-type custom field, so custom fields cannot be used as an upload route.
Demo mode
Installing the demo dataset switches on a write lockdown: while demo mode is active, every mutating request from a non-Super-User is refused.
- The lockdown works by matching write endpoints by prefix, so a newly added write endpoint is locked by default rather than needing to be remembered.
- The learner flow is exempt — taking an exam, LTI, session handling, the leaderboard opt-in and certificate download all still work, so the demo is actually demonstrable.
- It applies on the administrator and the site, since the management application runs on both.
Remove the demo data to restore normal writes.
Warning: installing the demo dataset is destructive. It truncates the content tables before seeding, so it produces an identical dataset every time — and will remove existing questions, exams and attempts. Install-seeded configuration such as settings, roles and email templates is preserved. Never install demo data on a production site with real content.
Logging
Operational failures — a webhook that would not send, a certificate that would not render — are written to the com_nextexams log category.
Nothing is written until you enable it, in System → Global Configuration → Logging. This follows Joomla's own convention for categories like deprecated and databasequery, and is deliberate: registering an always-on log file would write to disk on every installation for a background failure most sites never hit.
Next Exams specifically avoids Joomla's jerror category, because entries in that category are enqueued as user-visible messages. A failed webhook or a certificate render error would otherwise print internal English text onto whatever page an examinee happened to be looking at.
Transport
Use HTTPS. Examinee answers, access codes, API bearer tokens and LTI launch tokens all transit on every request, and none of them are safe in plain text.
Access control
| Action | Required permission |
|---|---|
| Handle a privacy request | Joomla's own privacy permissions |
| View cohort rosters | cohorts — view |
| Install or remove demo data | configuration — manage_settings |
| Enable the log category | Joomla Global Configuration |