Request and configure your own server certificate

ArcGIS Server is preconfigured with a self-signed certificate that allows the server to be initially tested and to help you quickly verify that your installation was successful. However, in most cases, an organization should request a certificate from a trusted certificate authority (CA) and configure the server to use it. This can be a domain certificate issued by your organization or a CA-signed certificate.

Like ArcGIS Server, the ArcGIS Enterprise portal also includes a preconfigured self-signed certificate. If you'll be federating your site with a portal, request a certificate from a trusted CA and configure the portal to use it.

Configuring a certificate from a trusted authority is a secure practice for web-based systems and prevents users from encountering any browser warnings or other unexpected behavior. If you use the self-signed certificate included with ArcGIS Server and the ArcGIS Enterprise portal during testing, you will experience the following:

• Warnings from your web browser or from ArcGIS Pro about the site being untrusted. When a web browser encounters a self-signed certificate, it typically displays a warning and asks you to confirm that you want to proceed to the site. Many browsers display warning icons or a red color in the address bar for as long as you are using the self-signed certificate.
• The inability to open a federated service in the portal's Map Viewer or Map Viewer Classic, add a secured service item to the portal, sign in to ArcGIS Server Manager on a federated server, or connect to the portal from ArcGIS for Office.
• Unexpected behavior when configuring utility services, printing hosted services, and accessing the portal from client applications.

For instructions on how to configure ArcGIS Enterprise with a CA-signed certificate, see the following topics:

• Import a certificate into the portal
• Configure HTTPS on ArcGIS Server using a CA-signed certificate
• Enable HTTPS on your web server

Scan for cross-site scripting attacks

Cross-site scripting (XSS) attacks inject and run code in existing web pages. The attacker often deceives the victim into opening that page with data or input the attacker provides. In ArcGIS Server sites, that input or data can be features returned by a feature service.

ArcGIS Server can scan features for potential XSS attacks. It can scan features when they are added or updated through the feature, and also when those features are sent to client applications. However, scanning for malicious code in a feature can lead to false positives or disable legitimate HTML that has been included in features for HTML pop-ups. The scanning behavior is configurable on a per-service basis.

By default, when services are created, they are usually configured to scan edits for potential scripts and block them but not to scan features retrieved from the feature service. An attacker may bypass this edit scanning by editing the features in ways that aren't scanned, such as directly editing the database through SQL. The most secure way to configure your services is to scan all features. Scanning every feature being retrieved for scripts may reduce performance, but it's a good security practice.

Changing the values on an individual service basis can be challenging to manage, so the preferred approach is to define a default value using the featureServiceXSSFilter property. This is a system property that is used when creating services. It has no effect on existing services and it can be overridden after a service is created.

To set this system property, sign in to the ArcGIS Server Administrator Directory and click System > Properties. The properties are represented by a JSON object. Copy the existing JSON object and modify it by adding the featureServiceXSSFilter property to that existing JSON object.

The featureServiceXSSFilter property can be set to input or inputOutput. The input value is the default; it directs ArcGIS Server to configure new feature services to scan edits. The inputOutput value directs ArcGIS Server to configure new feature services to scan edits and returned features.

To override a particular service's settings, you must use the ArcGIS Server Administrator Directory, find the particular service, and edit it. The three properties used on an individual feature service basis are the following:

• xssPreventionEnabled enables scanning for scripts and code in features. Set this to true.
• xssPreventionRule can be set to input or inputOutput. Edits are always scanned, but outgoing features are only scanned for scripts if inputOutput is the value. This overrides the system-wide featureServiceXSSFilter property.
• xssInputRule specifies the response when code is detected. The options are rejectInvalid or sanitizeInvalid. The rejectInvalid value is the default and is recommended.

Restrict file permissions

Set file permissions so that only necessary access is granted to the ArcGIS Server installation directory, configuration store, and server directories. The only account that the ArcGIS Server software requires access to is the ArcGIS Server account. This is the account used to run the software. Your organization may require additional accounts to have access. Keep in mind that the ArcGIS Server account must have full access to the installation directory, configuration store, and server directories for your site to function properly.

ArcGIS Server inherits file permissions from the parent folder where it is installed. Additionally, ArcGIS Server grants permission to the ArcGIS Server account so it can access the directory where it is installed. Files that are created as ArcGIS Server runs (such as logs) inherit their permissions from the parent folder. To secure the configuration store and server directories, set restricted permissions on the parent folder.

Any account that has write access to the configuration store can change ArcGIS Server settings that can normally only be modified by a system administrator. If a built-in security store is used to maintain users, the configuration store contains encrypted passwords for those users. In this case, read access to the configuration store should also be restricted.

If you use secured map or geoprocessing services, lock down file permissions on the server directories to ensure that unauthorized accounts don't obtain access to maps and geoprocessing job outputs.

Disable the primary site administrator account

The primary site administrator account is the account you specify when you create a site in ArcGIS Server Manager. Its name and password are recognized only by ArcGIS Server; it is not an operating system account, and it is managed separately from the user account in your identity store.

Disable the primary site administrator account to ensures that there is no way to administer ArcGIS Server other than by the group or role you've specified in your identity store. See Disabling the primary site administrator account for full instructions.

Define the shared key used to generate an ArcGIS token

An ArcGIS token is a string of encrypted information. The shared key is the cryptographic key used to generate this encrypted string. The more complex the shared key, the harder it is for a malicious user to break the encryption and decipher the shared key. If a user is able to decipher the shared key, replicate the ArcGIS Server encryption algorithm, and obtain the list of authorized users, the user will be able to generate tokens and consume any secured resource on that particular ArcGIS Server.

Before defining a shared key, consider the following:

• The shared key should be set to 16 characters (any characters beyond 16 are not used). It is recommended that you use a sequence of random characters for the key. Any characters may be used, including nonalphanumeric characters.
• The key should not be set to a dictionary word or a common value that is easily guessed. Since there is no need to remember the key or use it elsewhere, key complexity does not pose the same issues as it does with passwords.
• The token is encrypted with the shared key using the Advanced Encryption Standard (AES), also known as Rijndael. The 16 characters in the key represent the 128 bits used for encryption. For more information on encryption and AES, consult security references or someone in your organization with expertise in security and cryptography.
• In highly secure environments, it is recommended that you change the shared key on a periodic basis. Keep in mind that if you change the shared key, you may need to update your applications to use the new shared key. All existing embedded tokens will become invalid once you change the shared key.

To learn more, see About ArcGIS tokens.

Use a group Managed Service Account

Use a group Managed Service Account (gMSA) as the account that runs the ArcGIS Server service. Using a gMSA provides the advantages of an Active Directory domain account while keeping that account secure through periodic password updates.

Learn more about group Managed Service Accounts

Securely transmit ArcGIS tokens

To prevent the interception and misuse of tokens, use a secure connection that uses HTTPS. Using HTTPS ensures that the user name and password sent from the client and the token returned from ArcGIS Server cannot be intercepted. To learn more, see Secure ArcGIS Server communication.

When building custom ArcGIS client applications that use GET requests to access web services secured using ArcGIS token-based authentication, send the token in the X-Esri-Authorization header instead of a query parameter. This prevents intermediaries on the network—such as proxies, gateways or load-balancers—from obtaining the token. The example HTTP GET request below sends the token in the X-Esri-Authorization header:

GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
    Host: arcgis.mydomain.com
    X-Esri-Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-

If ArcGIS Server uses ArcGIS Server authentication rather than web-tier authentication (IWA, HTTP BASIC, PKI, and so on), the standard HTTP Authorization header can be used instead of the X-Esri-Authorization header:

GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
    Host: arcgis.mydomain.com
    Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-

Use standardized queries

ArcGIS Server includes a security option, known as standardized queries, that provides greater protection against SQL injection attacks. This option is enabled by default.

If you're a server administrator, it is recommended that you leave this security option enabled and instruct your application developers to construct WHERE clause statements that use database-independent syntax. Disabling this option may make your system more vulnerable to SQL injection attacks.

To learn more, see About standardized queries.

Disable the Services Directory

You can disable the Services Directory to reduce the chance that your services can be browsed, found in a web search, or queried through HTML forms. Disabling the Services Directory also provides further protection against XSS attacks.

The decision to disable the Services Directory depends on the purpose of your site and the degree to which it needs to be navigated by users and developers. If you disable the Services Directory, you may need to prepare other lists or metadata about the services available on your site.

For instructions on disabling the Services Directory, see Disabling the Services Directory.

Restrict cross-domain requests

Cross-domain requests are used in many system attacks. It is recommended that you restrict the use of ArcGIS Server services to applications hosted only in domains that you trust. To learn more, see Restricting cross-domain requests to ArcGIS Server.