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).
The tokens your users receive from OAuth 2.0 workflows (ArcGIS identity, application credentials, and the serverless web, serverless native and mobile, and server-enabled workflows) 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.
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 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.
Anyone in possession of your
client_ 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_, 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.
Choose ArcGIS identity 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.
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.
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.
Perform code reviews and validate adherence to your organization's security policy. Use a third-party testing service to verify your secure implementation.