Content Security Policy Project Update

This blog from the Instructure Product Team is no longer considered current. While the resource still provides value to the product development timeline, it is available only as a historical reference.

jfenton
Instructure Alumni
Instructure Alumni
2
1865

Last October we outlined a new security project for Canvas that gives institutions more control over the javascript that is allowed to run in their instance of Canvas through an updated Content Security Policy (CSP). We've been working hard to make this plan a reality and I'd like to post an update on our progress.

 

This project is comprised of three phases. The first phase changed the way we were serving up files in Canvas. The goal of this phase was twofold:

  • Make it clear that the files are not owned by Instructure, but rather by other Canvas users.
  • Limit how broadly user-granted permission was being applied. For example, if a user grants a file permission to access their webcam, permission will only be given for files in that course, and not for all files in that institution's instance of Canvas.

 

This first phase was deployed at the end of the year (view release notes here).

 

The second phase brings an updated CSP option to Canvas. The updated CSP will be opt in from a new Security Tab found on the account settings page. Institutions that don't opt in will have no changes made to their account. If an institution does choose to enable the updated CSP they will be able to restrict custom JavaScript (JS) that runs in their instance of Canvas based on domain.

  • This will be managed by a whitelist of acceptable domains. All JS that attempts to execute in violation of the whitelist will be blocked.
  • The whitelist has a limit of 50 domains. We recommend using wildcard domains (*.domain).
  • We will automatically add all necessary Instructure and Canvas domains, as well as any LTI tools that are configured on the account. These do not count toward the 50 domain limit.
  • Root account admins determine if sub accounts can manage their own whitelists. If so, sub accounts will have the option of either inheriting the whitelist from the parent account or managing their own whitelist.
  • Individual courses can be opted out of the CSP (for example, a computer science class that requires the ability to render student-submitted JS). Only account admins can opt a course out of the CSP.

 

This phase is currently in development. Our plan is to have this phase completed in the next couple of months.

 

The third phase adds a log to the UI which shows any requested domains that are in violation of the whitelist. This will allow admins to monitor activity and easily add new domains to the whitelist.

 

This phase is currently in the design stage and will begin development after phase 2 is released.

 

We're excited about the increased control this gives to institutions in managing the security for their instance of Canvas. As always, we'd love to hear from you. Let us know what you think in the comments!

Tags (1)

This blog from the Instructure Product Team is no longer considered current. While the resource still provides value to the product development timeline, it is available only as a historical reference.

2 Comments
Renee_Carney
Community Team
Community Team

Updates are available in the Canvas Release Notes (2019-04-20)

adam_c_voyton
Community Participant

Very cool and useful feature. Does this help with the third party cookie issue that some LTIs encounter?