There are widely known recommended best security practices to employ in your code and development processes. All client-side code is at risk of compromise, and a security breach in your application could lead to a hacker accessing services on your behalf, accessing resources to which they are not entitled, potential data loss, or other potential risks.
It important that you minimize your app's potential risks and exposure to harm, hacking, or security breach. This site cannot present comprehensive security advice or risk-mitigation, but offers a few, practical building blocks to help you think about building applications that use good security precautions throughout their design, development, and ongoing maintenance.
General tips
The following security best practices should be considered regardless of your chosen type of authentication:
| Best practice | Explanation |
|---|---|
| Use an ArcGIS API | The recommended workflow for applications requiring security is to use the appropriate client SDK object model to connect to and authenticate with ArcGIS Online |
| Use HTTPS | All ArcGIS Location Services require HTTPS. We strongly recommended that you host any web applications and services using HTTPS support. This helps prevent man-in-the-middle and packet sniffer attacks. Further, you should fully validate the certificate with a trusted certificate authority (CA). |
| Keep your application up to date | Maintain support for the most up-to-date web browsers and native devices in your application. Use the latest versions of APIs, SDKs, and client libraries whenever possible. |
| Session-based access | If your application's users are authenticated externally but remain unknown to ArcGIS, you can restrict access to your server-side component by authenticating each user session. This assumes that your app users are not malicious, but contains some risk. |
| Use a CAPTCHA | If you are worried about bots and automation driving up your usage, you can also implement a human validator (or Turing test) such as a CAPTCHA to differentiate humans from bots. Google's reCAPTCHA is a familiar implementation of this kind of validator that will not cause significant impact to your user experience, but does require that the application incorporate a CAPTCHA extension. |
| Adhere to a security policy | Perform code reviews and validate adherence to your organization's security policy. Use a third-party testing service to verify your secure implementation. |
| Send access tokens | Passing an access token in the HTTP header is generally more secure than including them in the URL query string. Query parameters may be logged in browser history, server logs, or intercepted more easily, potentially exposing sensitive information. |
API key authentication
API keys
| Best practice | Explanation |
|---|---|
| Never commit API keys | You should never commit sensitive information into a source control system such as Git or SVN. |
| Limit the privileges of keys | Limit the privileges |
| Access location services | API key authentication can be used to create public applications |
| Access private items (non-confidential data only) | API key authentication can be used to access private items |
| Don't use API keys for sensitive information | While API keys can be used to access private items and data layers, they should never be used to access information that is confidential. If your app needs to work with confidential information, use ArcGIS Online or ArcGIS Enterprise to implement a more secure type of authentication. |
| Use client referrers | Set up allowed referrers to restrict which clients are permitted to use specific API keys. While this can be circumvented, it adds a layer of difficulty for anyone wishing to abuse your keys. |
| Monitor key usage | Monitor usage of your API key to ensure it is used only by your applications. If you see unexpected spikes, rotate your API key for a new one. |
| Keep API key expiration short | You must set the expiration date of an API key |
| Rotate API keys regularly | Rotate and delete your API keys periodically and routinely, replacing existing API keys with new API keys. To learn how to rotate keys, go to API key credentials. |
| Invalidate unused keys | Proactively invalidate unneeded or older API keys to minimize the risk of exposure, or dissemination. |
| Require application sign-in | If you are building a public application |
| Authenticate in personal scripts | API keys can be used to provide authentication for personal applications intended for use only by you, the developer. API keys can be granted a limited set of privileges to support specific portal service |
User authentication
| Best practice | Explanation |
|---|---|
| Choose user authentication when possible | If your use case does not require your application to be public Requiring registration and/or sign in gives you more control over your app. You can more easily ensure that only authenticated users access private content and location services. |
| Protect your client credentials | Never expose your client or account login information. Anyone in possession of your client or other sensitive information could use that information to create access tokens and access content and services that are billed to your account. |
| Avoid embedding access tokens | Try to never include any sensitive information such as access tokens |
| Keep token expiration short | You can use an expiration parameter when requesting a token |
| Don't commit credentials | Never commit sensitive information into a source control system such as Git or SVN. |
| Use an OAuth 2.0 authorization code flow | User authentication supports several different workflows. Always choose a flow that adheres to the OAuth 2.0Authentication and Identity classes. |
App authentication
| Best practice | Explanation |
|---|---|
| Use app authentication instead of API keys | Both app authenticationclient and client are securely stored on a server-side component. App authentication should be used if a higher-level of security is required than API key authentication provides. |
| Authenticate for web servers | App authentication can be used to provide authentication for personal applications used by only you, the developer. If required in these situations, access tokens can contain privileges for portal service |
| Access location services | App authentication can be used to create public applicationclient or account login information. Anyone in possession of your client or other sensitive information could use that information to create access tokens and access content and services that are billed to your account.
| Avoid embedding access tokens | Try to never include any sensitive information such as access tokensclient into a source control system such as Git or SVN. |