Security best practices

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 can only be used to access location services and secure items in a portal.
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.

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_secret or account login information. Anyone in possession of your client_secret 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 AuthenticationManager and IdentityManager classes.

App authentication

Best practice	Explanation
Access location services	App authentication can only be used to access location services and secure items in a portal.
Use instead of API keys when possible	Both app authentication and API key authentication are used to build public applications with equivalent privileges. App authentication provides significantly more security for your application, as access tokens expire after 2 weeks and the client_id and client_secret are securely stored on a server-side component. If possible, app authentication should always be used instead of API key authentication. This requires your app to have a server-side component.
Protect your client credentials	Never expose your client_secret or account login information. Anyone in possession of your client_secret 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.