Canvas - Safety Rules for Personal Apps, Scripts, Extensions, and API Tokens

• Explore and build responsibly
  • Personal use or a custom application?
  • Understand the access your tool uses
• Never give your token to anyone
• Prefer a personal browser extension when possible
• If a token is necessary, expire it within two weeks
• Never commit a token to source code
• Store the token securely, separate from your script
• Protect access while your tool runs
• Revoke tokens when you finish
• If a token is exposed: revoke and report
• Official references and help

Explore and build responsibly

You may build personal tools that work with Canvas. That might mean automating a repetitive task, exploring course information, or trying a different way to display a page. Experimentation is welcome. Protecting the people and information in Canvas is part of the work.

Start by checking whether an existing Canvas feature or approved integration already meets your need. If you build something yourself, use only your authorized access, protect university data, and follow the requirements below. Permission to experiment does not replace any university review required before introducing a tool into a course, sharing student information, or distributing an integration to others.

Personal use or a custom application?

For a tool that you alone use for your own work, a personal browser extension or a script using a personal API token may be appropriate, provided you follow all the safeguards in this article. Prefer an extension when it can meet your need without a token.

If anyone else uses your tool and relies on it to get work done, treat it as a custom application. This applies even if only one other person uses it, the tool is small or free, or each person runs a separate copy. Follow Canvas - Requesting and Approving a Custom Application and contact CASL before introducing it for that use. The custom application must meet that article's review, approval, and LTI 1.3 with OAuth 2.0 requirements; personal tokens do not replace those requirements.

Understand the access your tool uses

Canvas provides an application programming interface (API): a way for your code to request information or perform actions in Canvas. A script written in Python, R, or PowerShell can use that API to do work you would otherwise do through the website. Those requests can affect real courses and real people, so understand what your code will read or change before running it.

A personal API access token, also called a bearer token, is a credential your code can use to act with your Canvas permissions. Anyone who obtains it may be able to do the same. Treat it like your password, keep it out of your code, and give it a short expiration. Instructure's guide to managing API access tokens explains the Canvas controls; the sections below set out the requirements for using them responsibly.

Never give your token to anyone

Do not share your token with colleagues, students, collaborators, support staff, vendors, websites, or AI tools. Do not paste it into an application supplied by someone else. Never ask another person to give you a token or generate one for your tool.

You may share credential-free code, but never share a token. If anyone else uses the tool and relies on it for work, the custom application requirements apply, including LTI 1.3 with OAuth 2.0. Asking each person to supply a personal token does not satisfy those requirements.

Prefer a personal browser extension when possible

If you proceed with a personal customization, prioritize an extension for Chrome, Edge, or Firefox that works within the Canvas pages you have already opened. A display customization can use information already on the page without creating a personal API token. An extension does not automatically make every API operation token-free.

Limit the extension to the Canvas site and the permissions it needs. Do not extract cookies, copy session credentials, bypass security controls, or send Canvas information to external services. If a university-managed browser blocks development extensions, contact support rather than bypassing the restriction.

Use browser developer mode only when you need it to load or test your own extension. Normal Canvas use and installing an extension from an official browser store do not require it. Do not enable developer mode just because an unfamiliar tool or website asks you to. When testing is complete, remove temporary or unpacked extensions you no longer need and turn developer mode off when it is no longer required. Do not confuse this with the browser Developer Tools used to inspect a page.

For instructions on creating and testing personal extensions, use the browser vendors' documentation:

• Chrome: create and load a first extension
• Edge: load and test a local extension
• Firefox: create and temporarily load an extension

If a token is necessary, expire it within two weeks

For a manually created personal token, set an explicit expiration date and time no later than 14 days after creation. Use a shorter lifetime if the work will finish sooner. Never leave expiration blank or accept a longer default.

In Canvas, open Account > Settings > Approved Integrations. If token creation is available, enter a clear purpose and explicitly set the expiration before generating the token. A purpose such as “read-only report” describes your intent; it does not restrict the token's permissions. Confirm the date, time, and applicable time zone.

Record the purpose and expiration date without recording the token value. When a token expires, stop the script and reassess whether access is still necessary before creating a replacement with another maximum 14-day lifetime. Revoke it sooner when the work ends. This requirement concerns manually created personal tokens, rather than the separate lifecycle of approved OAuth integrations.

See Instructure's instructions for creating, reviewing, and deleting tokens. If the controls are unavailable, contact support; do not borrow someone else's token.

Never commit a token to source code

This applies to private repositories as well as public ones. Keep tokens out of scripts, notebooks, configuration files, examples, test data, documentation, and saved outputs. Check staged changes and notebook outputs before committing or sharing. Use secret scanning where available.

A .gitignore entry does not protect a token already tracked or committed. Deleting the current line or latest commit does not remove earlier copies. If a token enters version control, revoke it immediately.

Store the token securely, separate from your script

Preferred: your device's credential store. Store the token in macOS Keychain, Windows Credential Manager, or a supported Linux secret store, and retrieve it when the script runs. Store the token, rather than the script, in the credential store. Use a secure operating-system backend, not a plaintext keyring.

• Python: the keyring documentation covers supported credential stores and set_password() / get_password().
• R: the keyring documentation covers system credential storage and key_set() / key_get().

PowerShell: use Microsoft's SecretManagement documentation to connect PowerShell to a secure registered vault. An encrypted local vault such as Microsoft SecretStore is an option when an appropriate operating-system credential-store integration is unavailable. Keep its password protection enabled.

After installing the modules and registering a vault as described in Microsoft's instructions, use Set-Secret without a literal token value so it prompts for hidden input. Retrieve it inside the script with Get-Secret and assign the result to a variable; do not print it. For PowerShell 7 API requests, Invoke-RestMethod supports -Authentication Bearer -Token with a SecureString. Keep the token secure in memory and avoid transcript or debugging output that might reveal it.

Fallback: a temporary environment variable. If a secure credential store is unavailable, supply the token through an environment variable limited to the process or session running your script, then remove it after use. Environment variables are not encrypted credential storage and may be exposed in diagnostic output or inherited by child processes.

See PowerShell's environment-variable documentation for session scope, and Python's os.environ or R's Sys.getenv() for retrieving a value in your script. In PowerShell, read a session variable as $env:CANVAS_API_TOKEN and remove it afterward with Remove-Item Env:\CANVAS_API_TOKEN. Do not use setx or a User/Machine-scoped variable to make a token persistent. Do not hard-code the token while setting the variable or enter it in commands saved in shell history. Do not save it in shell profiles, persistent user/system variables, .env or .Renviron files, or saved workspaces.

Protect access while your tool runs

Use only your authorized Canvas access and collect only the information necessary for the task. Protect exported course and student information. Start with read-only operations and non-sensitive sample data wherever possible; review changes before applying them to a live course.

Use HTTPS and send the token only to the intended Canvas host in the Authorization: Bearer header. Never put it in a URL, forward it to another host, print it, or include it in logs, screenshots, error reports, or environment dumps. Course rules, privacy obligations, and applicable university review requirements still apply. See Instructure's token-storage guidance, API authentication instructions, and Canvas API Policy for additional requirements, including privacy and rate limits.

Revoke tokens when you finish

In Canvas, open Account > Settings > Approved Integrations, locate the personal token, select its delete/trash control, and confirm deletion. Removing a token from your computer alone does not revoke it in Canvas. See Instructure's access-token management guide for the current controls.

If a token is exposed: revoke and report

Treat a token as exposed if it was shared with another person, pasted into an AI tool or another application, committed to a repository, or included in logs, messages, or saved outputs. Respond even if you have not seen misuse, the repository is private, or the message has been deleted.

1. Revoke it immediately in Canvas. Do not wait for expiration. If you cannot sign in or revoke it, call the UWM Help Desk at 414-229-4040 for access assistance and report the suspected exposure to Information Security using the routes below.
2. Report the exposure to UWM's Information Security Office. Email infosec@uwm.edu or submit the Cybersecurity Incident Form. These are the reporting routes in UWM's Required Security Practices. Report suspected incidents without waiting to prove unauthorized access.
3. Describe what happened without sending the token. Include your contact information, the affected Canvas account and token purpose/label, when and where exposure occurred, whether the token has been revoked, and any suspected unauthorized activity or affected course information. Do not include the token value in an email, form, screenshot, or attachment. Tell Information Security what logs or other evidence are available and follow its instructions for sharing them securely.
4. Coordinate cleanup and preserve evidence. Restrict further exposure and follow Information Security's instructions before deleting incident records or rewriting repository history. Remove token values from working files and arrange cleanup of exposed messages, outputs, and repository history as directed. Deleting only the latest line or commit does not remove earlier copies, and cleanup does not make an exposed token safe to reuse.
5. Replace only if still necessary and authorized. After revocation, create a new token with a maximum 14-day lifetime, store it securely, and update the script's credential-store entry. Do not reuse the exposed token.

Official references and help

• Instructure: manage API access tokens — create, review, and delete personal tokens.
• Instructure: OAuth2 and Canvas API authentication — manual tokens, secure storage, authentication headers, and multi-user applications.
• Instructure: Canvas API Policy — requirements for API use.
• UWM Canvas support contacts — existing Canvas capabilities and approved alternatives.