Guides
SCORM Security Risk
SCORM is a technology that allows you to author and distribute e-learning modules. It is the industry standard for e-learning, Instructional Design, and Corporate Training. SCORM is part of the Advanced Distributed Learning (ADL) a program championed by the Office of the United States Secretary of Defense.
If you want an impartial evaluation of the dangers of SCORM find a friend who's a senior software engineer and say this to them (don't worry if you don't know what any of the technical language means):
If there was an application that served arbitrary user-input JavaScript and HTML to every user's browser across an organization or business, would that spook you?
They will respond: "YES, PLEASE don't do that, why are you doing that?"
What you just described to your friend is the fundamental mechanic of SCORM.
SCORM does something very different from most technologies: it sends non-sterile code to anyone who accesses the SCORM module.
Typically, when you are using software the code is totally "sterile". It comes from a secure server and is "clean". In other words, you know the code you are running has not been shared or tampered with. It comes from the server that your IT department created. The only person you need to trust is the IT folks.
SCORM does something very unusual in software. It makes the software's code completely editable to anyone who has ever accessed it. So any person that has ever had access to the SCORM module, be it a vendor, an L&D professional, an intern... ANYONE can add any code they want. This "non-sterile" code is then distributed to everyone in your organization.
If you are wondering, "Does that mean a person could add malicious code to an e-learning module to steal passwords?!", the answer is, unfortunately, yes. Because of SCORM, a bad actor could do almost anything with your organizational data.
In other words, to safely run SCORM modules in your organization, you don't just need to trust your IT team, you need to trust every single person who has ever had access to the SCORM module.
If you are thinking, "Is JavaScript the problem?" No, JavaScript is totally fine.
Most modern web technologies are built in JavaScript frameworks: React, Vue, or Angular. These technologies allow you to use your favorite JavaScript-based SaaS technologies securely.
If you think back to that question you asked your engineer friend:
"If there was an application that served arbitrary user-input JavaScript and HTML to every user's browser across an organization or business, would that spook you?"
This is exactly what React, Vue, and Angular strongly advise you never do.
In other words, React and Vue will strongly advise against doing the core operation on which SCORM relies: JavaScript injection.
Vue.js explicitly warns against v-html and never allows direct script execution through it.
React doesn't even have a normal API for injecting HTML - you have to use dangerouslySetInnerHTML (the name itself is a warning!)
Angular sanitizes HTML by default and requires bypassing security APIs to inject raw HTML.
These frameworks, the standard for good internet development, treat user-provided or third-party HTML/JS as inherently dangerous. They would never allow you to take the kind of security risks required for even a basic SCORM module to run.
Here's how simple an attack could be:
An employee downloads a SCORM module to 'improve' it. They unknowingly add compromised code (or do so intentionally). When re-uploaded, every colleague who takes that training is now exposed. In minutes, credentials, financial data, or intellectual property could be exfiltrated from thousands of machines.
Unfortunately, your learning management system cannot solve this SCORM problem. The learning management system has no way to "block evil JavaScript" because it has no idea which JavaScript is "evil". Accordingly, when a learner accesses the SCORM content, everything (good and bad) gets run.
Some learning management systems offer reassurance that the course is "sand-boxed" in something called an "iFrame". While these iFrame implementations offer some protection, they would not prevent a basic phishing attack: the LMS has malicious code that asks the user for their password and then sends it to a bad actor. Accordingly, iFrames should offer virtually no reassurance, no matter how stringently they are configured. The core mechanic, "arbitrary third party JavaScript" remains.
Excitingly, there are many projects working to share course content as pure data (JSON). This, as an architectural decision, completely removes the risk of malicious JavaScript making its way into your organization.
PRIXL - A brand new fully JSON-based course standard. This allows you to author all of your training modules with video, text, diagrams, quizzes, etc, just like you would in SCORM except it is shared as pure data (JSON) not as code. So no risk of attack. Interestingly, in the world of AI, it should also be noted that PRIXL was designed to support "vectorization" of learning events, so you can train AI models with learning outcomes.
xAPI - Not a perfect alternative to SCORM because, unlike SCORM and PRIXL, you cannot use xAPI to author content. That said, it is an elegant way to report digital and in-person learning events.
cmi5 - A further formalization of xAPI, again offers a JSON based reporting schema. It does not; however, support content authoring like SCORM or PRIXL.