Request and configure your own server certificate

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

Like ArcGIS Server, the ArcGIS Enterprise portal also comes with a preconfigured self-signed certificate. If you'll be federating your site with a portal, you should 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 will also prevent users from encountering any browser warnings or other unexpected behavior. If you choose to 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, from ArcGIS Desktop, or from ArcGIS Pro about the site being untrusted. When a web browser encounters a self-signed certificate, it will typically display a warning and ask 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, add a secured service item to the portal, log in to ArcGIS Server Manager on a federated server, or connect to the portal from ArcGIS Maps 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
• Configuring 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 that 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 to block them but not to scan features that have been retrieved from the feature service. An attacker may bypass this scanning of edits by editing the features in ways that don't get scanned, such as directly editing the database through SQL. It's therefore most secure to configure your services to scan all features. Scanning every feature being retrieved for scripts can lead to slower 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 system property. This is a system property that is used when creating new services. It has no effect on existing services and it can be overridden after a service has been created.

To set this system property, sign in to the ArcGIS Server Administrator Directory and go to the System > Properties resource. The properties are represented by a JSON object. It's important that you 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 either input or inputOutput. The input value is the default; it tells ArcGIS Server to configure new feature services to scan edits. The inputOutput value tells ArcGIS Server to configure new feature services to scan edits and scan returned features.

If you want 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:

• xssPreventionEnabled enables scanning for scripts and code in features. It's recommended that this always be set 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 determines what is done when code is detected. The options are rejectInvalid or sanitizeInvalid. The rejectInvalid value is the default behavior and is recommended.

Restrict file permissions

It is recommended that file permissions be set 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 being used to run the software. Your organization may require that additional accounts also be given access. Keep in mind that the ArcGIS Server account needs 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. If you want 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 an administrator of the system. If a built-in security store is being 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 have secured map or geoprocessing services, it's important to 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 first 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.

It's recommended that you disable the primary site administrator account. This ensures that there isn't another way to administer ArcGIS Server other than 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.

Securely transmit ArcGIS tokens

To prevent the interception and misuse of tokens, the use of a secure connection using HTTPS is recommended. The use of 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 Configure HTTPS on ArcGIS Server.

When building custom ArcGIS client applications that use GET requests to access web services secured using ArcGIS token-based authentication, it is recommended that the token be sent 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 being able to obtain 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 and not Web-tier authentication (IWA, HTTP BASIC, PKI, etc) the standard HTTP Authorization header may 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 could 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 cross-site scripting (XSS) attacks.

The decision to disable the Services Directory will depend 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 to create 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 a recommended practice to 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.