Skip to content
Security

Built to keep every organisation's data its own.

Security is not an add-on in onlms. Isolation, least privilege and accountability are part of how every feature works.

  • Tenant isolation on every request
  • Every change in the audit log
  • Least-privilege roles
  • Throttled, hashed sign-in

Tenant isolation

  • Every organisation is a separate account. Its users only ever see that account's people, roles, courses and records.
  • The account boundary is enforced in the server for every request, not just hidden in the interface.
  • Asking for another organisation's records returns "not found", so nothing reveals that they exist.
  • Course files are stored per organisation, outside the public web folder, and served only after an access check.

Access control

  • Built-in roles for administrators, instructors and learners, plus custom roles per organisation.
  • Nobody can grant a permission they do not hold themselves, so roles can never be used to escalate access.
  • Safeguards keep at least one active administrator in every organisation.
  • People cannot change their own roles or status: that always takes a second person.

Sign-in and sessions

  • Passwords are stored only as salted, one-way hashes.
  • Repeated failed sign-ins are throttled per e-mail address, per network address and per combination of both.
  • Sign-in answers the same way whether or not an e-mail address is registered.
  • Other sessions end when a password or e-mail address changes, and every session ends when a user is deactivated or an organisation is suspended.
  • Idle sessions expire; session cookies are HttpOnly, SameSite and Secure over HTTPS.

Audit trail

  • Every change to accounts, users, roles, settings, courses and enrolments is written to the audit log together with the change itself.
  • Sign-ins, failed attempts and sign-outs are logged with IP address and browser.
  • Support access ("sign in as") needs its own permission, can never be used to become a super administrator, and every action taken names the real person behind it.
  • Passwords and security tokens never appear in the log.

Application hardening

  • A strict Content Security Policy: no inline scripts, and third-party assets only from pinned, integrity-checked files.
  • Every form carries a CSRF token, and other sites cannot embed the application in a frame.
  • HTTP Strict Transport Security over HTTPS, and pages of signed-in users are never cached.
  • Database queries are always parameterised.

Course content

  • SCORM packages can be served from a separate content domain, away from the learner's signed-in session.
  • Uploads are checked for size, number of files and unpacked size before a package is accepted.
  • Package manifests that declare XML entities are rejected.
  • Text in slides is sanitised, so authored content cannot run scripts in a learner's browser.
Accountability

Who did what, when, and from where

The audit log answers the questions auditors ask, for your whole organisation, without anyone having to reconstruct events from memory.

  • Filter by action and search by person or description
  • Role changes are recorded with the permissions added and removed
  • Support access is visible, with the support agent's own name

Found a security issue?

Please tell us privately, with the steps to reproduce it, before sharing it with anyone else.

Report an issue

Questions from your security team?

We are happy to walk your IT and compliance colleagues through how onlms handles your data.

Request a demo See pricing