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 rather than to program abstractly using REST API. Connecting and authenticating via the client SDKs frees you from both managing authentication details as well as from the responsibility to safely handle user credentials during the authentication process. |
| 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 token expiration short | You can use an expiration parameter when requesting a token to establish the length of time in which that token is valid. By requesting shorter tokens, you limit the time-frame when an attacker could use a compromised token. |
| 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. |
API key authentication
API keys are designed to be included in public-facing applications, for example embedding them within a web application. This means that your API key could be exposed to any of your application's users. In order to prevent abuse of your API keys, we recommended the following best practices:
| Best practice | Explanation |
|---|---|
| Access location services | API keys are the recommended method to access location services and secure items in public application. |
| 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 of your API key to prevent misuse. |
| 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. |
| 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 for users without an ArcGIS accounts, you may prefer to request that users register to use your application in order to reduce public access to your API keys. |
| Authenticate in personal scripts | API keys can be used to provide authentication for personal automation scripts used by only you, the developer. In these situations, it is safe for API keys to contain privileges with a personal scope. |
User authentication
| Best practice | Explanation |
|---|---|
| Choose user authentication when possible | If your use case allows for your application to be private, always choose user authentication over other authentication methods. If your users do not have ArcGIS accounts, you may prefer to request that users register to use your application in order to reduce public access to your API keys. 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 as literal strings in your code. |
| 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.0 specification, specifically the Authorization code flow for server-side apps and the Authorization code flow with PKCE for client applications. All ArcGIS Maps SDKs already implement an authorization code flow with PKCE by default via the Authentication and Identity classes. |
App authentication
| Best practice | Explanation |
|---|---|
| Authenticate for web servers | App authentication can be used to implement authentication in web servers and automation scripts. In these situations, it is safe for your developer credentials to have privileges with a personal scope. |
| Access location services | App authentication can be used to make public application that access location services and secure items in a portal. |
| Use instead of API keys when possible | Both app authentication and API key authentication can be used to build public applications. App authentication provides significantly more security for your application because the access tokens expire after 2 weeks and the client 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. However, this requires your app to have a server-side component. |
| 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 as literal strings in your code.
| Don't commit credentials | Never commit sensitive information such as your client into a source control system such as Git or SVN. |