App Cloud
- Overview and general topics
- Product Updates
- Glossary
- The App Cloud SDK
- Creating an app template
- Tutorials
- Content optimization
- Development tips and best practices
- Packaging a template
- Creating apps from a template
- Publishing an app
- Delivering ads
- Push Notifications
- Analytics
- Managing users and accounts
Player Debugger
Resources
Media API: Security Best Practices
The Media API is a REST-based service accessed over HTTP, which makes it very easy to interface with from your client- and server-side applications. However, this ease can prove to be a weakness in your application if you overlook designing your system for security from the outset.
Designing for security should be part of every web-application endeavor. It essentially means identifying the sensitive information and resources in the system, determining where they are and how they're accessed, and ensuring that the location and access controls effectively keep unauthorized users out and information secure.
The recommendations in this document pertain specifically to your application's interaction with the Media API and assume that you've secured the rest of your application.
Know what's at risk
The lynchpin of security in the Video Cloud API is the API token. An API token is an alphanumeric string is appended to API calls to "authenticate" your application with the system and permit the transaction. There are three separate token types, one for each of:
- read API calls
- write API calls
- read API calls, with access to the video file URL
For more information, see Managing Media API Tokens.
The Media API doesn't check anything besides the presence and validity of the token when verifying authenticity, so anyone who has your token can make an API request against your account.
Since the Media Read API is read-only, the risks are limited, however not to be ignored. At risk is your metadata and assets, including content that is outside of scheduling windows or otherwise should not be viewable by the public. With direct access to the content, a hacker could easily grab content without your knowledge and without traceability. For the Media Write API, the risks are more serious, since write methods can create, modify, or delete your video assets.
Protecting your API tokens on the client
Client-side scripting involves any scripting language that executes in the browser or a browser plug-in, including ActionScript, JavaScript, VBScript, to name a few. Script files are tied to the page-state, and typically loaded in the <head> section of the page. Generally, anything a browser loads can be viewed by the browser's owner, and script files are typically written in plain, human-readable text. If your token is in here, anyone can get it.
The alternative to placing your token in your client script is to not actually place it there. Instead, create a simple server-side script, in PHP for example, that proxies the request to the API interface and its response. Then ensure the script is placed in a protected directory that can't be listed and that the script itself can't be loaded directly into the browser.
Protecting your API tokens on the server
Having your token in a server-side script is a great deal more secure than placing it on the client. However, there are additional ways to ensure your token isn't compromised when it's on the server.
Factor the key out of the functional scripts and into a settings file that you can protect with more secure permissions that the script itself. The script file can do a dynamic include to retrieve it as needed, but the settings file doesn't need to be accessible directly to the browser, as the script does.
This choice is especially recommended, because it makes for cleaner code. If your token was compromised and you needed a new one issued, the process of swapping the new one for the old one would be far shorter.
Finally, remember that the fewer people who have access to a token, the less likely it is for the token to be compromised by improper handling.
Protecting your API tokens on the wire
To guard against attempts to sniff out your tokens, consider making your API requests via HTTPS, rather than HTTP. All you need to do to use HTTPS is to make your API call with the https:// protocol, instead of http://. The "s" stands for "secure," and instructs the browser to encrypt the transaction, including your token. There are performance drawbacks to using HTTPS, because the server and browser need to encrypt and decrypt the traffic.
