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.


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).

Access tokens

The tokens your users receive from OAuth 2.0 workflows (including user authentication workflows and the app credentials workflow) can be used for any applicable ArcGIS premium content or location service. If you expose a token in the open, such as via an insecure browser or client app, another developer or attacker could copy the token and then use it to make requests on your behalf. These spoofed requests would then be billed to your own or your user's account, depending upon the type of application and the services established for the app and user.

It is therefore strongly advisable that you encrypt or take other precautions to avoid exposing your tokens.

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.

API key security

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:

  • You should never commit sensitive information into a source control system such as Git or SVN.
  • Limit the services to which your key is allowed access.
  • 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 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.
  • Delete unneeded or older API keys to minimize fatigue, exposure, or dissemination.
  • Rotate and delete your API keys periodically and routinely, replacing existing API keys with new API keys.

Protect sensitive information

Anyone in possession of your client_secret or other sensitive information could use that information to, for example, create tokens and then use those tokens to access content or services which are billed to your account. As with API keys:

  • Never expose your client_secret, tokens, or passwords.
  • Avoid revealing sensitive information to unauthorized parties.
  • Try to never include any sensitive information as literal strings in your code.
  • Avoid committing sensitive information into a source control system such as Git or SVN.

Implement user authentication when possible

Choose user authentication over API keys if your users have access to an ArcGIS Online organization. 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.

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.


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.

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.

Rate limits and miscellanous restrictions

Your application can also restrict which functionality is exposed by the server-side component, place IP restrictions on the server-side component, or build rate limits into the component as appropriate. Rate limits can prevent misuse of the server-side component from malicious external code. This option only applies to JavaScript, Swift, Kotlin, and similar client devices.

Adhere to 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.

Your browser is no longer supported. Please upgrade your browser for the best experience. See our browser deprecation post for more details.