Securing Your xAPI Statements in JavaScript

xAPI unlocks many new possibilities for learners to engage in learning without the traditional cumbersome process of logging in to an LMS to have access to eLearning content. One of the things we must still consider, especially when building learning experiences in front end languages, is security. The following are a few ideas for keeping LRS information safe if you’re just dealing with client-side, but it should be noted that it could be even safer if the LRS communications were handled through a backend or API.

Restricting LRS / Activity Provider access

Most LRS’s provide the ability to give limited access to an activity provider through an administrative dashboard. Below is an example from Watershed. Notice that for our “Tin Can Statement” activity provider, we have both Isolated the LRS Access and disabled the API Access.

This also allows you to obtain new credentials ( key & secret ) so if you want to be extra safe while still keeping the same activity provider, you could update those on a regular basis while also updating the credentials in your front-end code.

Force HTTPS for your Basic Auth

Basic Auth – by its very nature – is not very secure. It’s just the username and password put together and Base64 encoded. That’s why it’s important to make sure the server or host we’re using for our xAPI project enforces https as well.

For credentials and Basic Auth with xAPI – we recommend using a wrapper like ADL’s xAPI Wrapper.

They even provide examples on configuring their wrapper to use Basic Auth. For example, if our Key was mykey and our secret was mysecret, we could setup basic auth in the xAPI wrapper like so:

var conf = {
"endpoint" : "https://lrs.adlnet.gov/xapi/",
"auth" : "Basic " + toBase64('mykey:mysecret'),
};
ADL.XAPIWrapper.changeConfig(conf);

For the HTTPS enforcement – if you are able to edit to the .htaccess file, the following would ensure the users are always redirected to the https version of the site, even if they type http://

RewriteEngine On
RewriteCond %{HTTP_HOST} ^learningdojo\.net [NC] RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.learningdojo.net/$1 [R,L]

Obfuscate and minify front end code

We know Basic Auth doesn’t provide much security, especially if someone is looking at our javascript and can see the key and secret in plaintext. That’s why it’s important to also obfuscate the code as much as possible, so it it can deter or make things more difficult for someone who wants to misuse the credentials. It should be noted, a determined intruder could still reverse obfuscation, but doing so makes it one step harder for them to obtain.

For example, here are several approaches to obfuscation, with the original code on the left and the obfuscated result on the right:

By doing this obfuscation ( several times through several different services if possible ) we can slow down and deter all but those who are really committed to breaking in.

Conclusion

As stated at the beginning – no amount of client-side security can compete with the vault that is backend code, so we highly recommend investigating that route. However, if you only have constraints with your xAPI project that only allow you to work in Javascript or another front end language, we would encourage you to follow the setup tips above to make it as safe as possible.

 

Leave a Reply

Your email address will not be published. Required fields are marked *