Tokens

Guidelines on using App-ID token pairs securily.

• Keep your App-ID & Token pair safe. If in doubt, delete it and create a new one.
• App-ID & Token pair should be used for one use-case only. For multiple use cases generate multiple pairs.
• If users are using your application that integrates with iconik it's better to provide an authentication mechanism than use App-ID Tokens continuously.
• If your use case is one of sufficient need, consider automatically rotating keys daily/weekly/monthly.
• Do not share you App-ID Token pair with another user. If they need one generate a new pair for them, preferably using their user account.
• Never make publicly available your tokens, particularly not to publically accessible source code repositories such as GitHub.
• For applications with a high need of security consider using a tool for managing secrets such as Vault by Hashicorp.
• Don't create token that are bound to administrator accounts.

Users and roles

Users should be created for each physical user that will be using the system. iconik maintains audit logging of every action a user performs against the API, which also means our integrations, applications and web interface.

• Restrict the roles that a user has to just what they need and no more.
• If a user is to have API access double check the roles that they need to perform their API task.
• Use user groups to make the administration easier.
• Don't let users share login credentials, particularly not for the administrator accounts
• Sufficiently train your users in the use of iconik, particular in areas that would allow them to delete, modify, share or send sensitive content out.
• Likewise for anyone developing against iconik, make sure that they understand the consequences of operations against resources that could delete or modify entities. Let them develop against test data first.
• Make sure that users pick a strong password for their account.

Cloud Storage

If you have setup iconik to use your own cloud storage please check the following:

• Restrict the access that is needed by iconik to be the bare minimum that we require. We will warn you in the GUI if we don't have sufficient rights.
• Don't share the iconik Cloud storage access credentials anywhere else.
• Use our API for Cloud Storage if you require to rotate those access credentials regularly.
• Turn on audit logging, and any other security logging features for the Cloud buckets.
• Make sure that the cloud storage audit logging information itself is secure, such as logging to another bucket with restricted access.

CORS

When integrating JavaScript from another service to talk to iconik you might get No 'Access-Control-Allow-Origin' header and the request will not work.

At the moment we do not support adding custom Allow Origin headers for Cross Origin Requests for security reasons.

Work arounds:

• Use our REST API from your backend services and properly authorize users and authenticate against our APIs.
• Use a proxy such as nginx to proxy all requests from your web application, through the proxy to our backend servers.

Other

Other guidelines:

• Use HTTPS where ever possible.
• Properly secure and keep patched any machine and/or network that integrations with iconik. Such as
  • iconik Storage Gateway servers.
  • NLE workstations using iconik
  • Your own integration servers
• Consider security scanning content that will be uploaded into iconik. Media Files, Spreadsheets, PDFs and many other filetypes are at risk and even if it has no consequence to iconik, end users will still be able to download and distribute them using iconik.