Security Best Practices

dotCMS is committed to providing the highest level of security for our products and customer sites. We demonstrate that commitment by internally reviewing and scanning all our code for vulnerabilities, keeping up with the latest security concerns and tools, and addressing security issues and potential vulnerabilities proactively.

This document lists a number of security best practices. We recommend that you read this entire document before publishing your own sites with dotCMS, and we strongly recommend that you implement these best practices for any production server, especially any public-facing server.

Note: The following security practices are implemented by dotCMS for all dotCMS cloud clients. For more information on dotCMS Cloud, please contact dotCMS Sales.

Recommended Approaches

Although specific configurations and practices are necessary to implement strong security, it is often just as important to adopt an overall approach to security that ensures that, when resources are scarce or there are conflicting needs, appropriate choices can be made about which specific security practices to implement. The following are some approaches we recommend to help you identify, implement, and manage your security practices for your dotCMS site.

Continual Improvement

Maintaining security of web sites can be a very complex and rapidly evolving challenge for organizations of any size, and even this relatively long list of best practices is not comprehensive. It may be difficult to implement all of these best practices for all sites, or to implement all of these practices for new sites.

However since security is always changing, it is best to take an approach of continual improvement. Therefore, even if it is not possible or practical for you to implement all of these best practices immediately, we recommend that you implement as many as you can now, and then progressively implement additional practices as you are able to.

Layered Security

Individual security measures may be defeated by determined attackers, and vulnerabilities may be discovered at any time in even long-standing security protocols. Therefore it is best to implement multiple layers of security for every potential access point, to ensure that one or more layers of security remain even if one layer is compromised or defeated.

In simple terms, this just means that you should, when possible, implement as many of these best practices as you can. Most of these practices overlap with each other, so you will automatically achieve multiple layers of security in some areas when multiple best practices are implemented and maintained. As you continue to improve, or in order to address specific security concerns, you may review your practices to ensure you have multiple layers of security covering specific areas of concern.

White List Access

It is very difficult to anticipate all possible attacks and vulnerabilities that may be attempted or exploited in the future. This makes it extremely difficult to implement security using a “black list” approach, attempting to filter or limit malicious behavior.

It is instead both easier and more secure to implement a “white list” approach, where you only allow a small set of acceptable behavior, and reject all access or behavior which does not meet your requirements. Therefore, whenever possible, it is best to use a “white list” approach, and explicitly define and enforce what is allowed. It is much easier to expand the list of allowed actions later (when a user is unable to perform their required tasks) than it is to detect and close a vulnerability after it has been exploited.

Server Configuration

The applications you run on your server, including dotCMS, can only be as secure as your server itself. If your server security is compromised, efforts to secure dotCMS can not protect your server and site from being compromised. Therefore it is vital that you ensure you configure your server for maximum security.

The following are several steps you can take to increase the security of your server.

Run dotCMS on a Dedicated Server

We strongly recommend that dotCMS be run on its own dedicated server. In addition to improving the performance and reliability of the server, this also eliminates the need for additional services and applications and additional open ports which could provide access points to attack the security of your server.

Disable all Unused Ports

Malware often targets services that run on dynamically-allocated (autowire) ports. Therefore it is important that you use a firewall to prevent access to these ports to protect against potential zero-day (unpatched) vulnerabilities.

Block access to all ports except Connectors for your application server, from all sources outside of the dotCMS cluster. This includes blocking access to these ports from all non-dotCMS sources on the same subnet of your internal or DMZ subnet.

Disable or Uninstall All Unused Services and Applications

You should run only the minimum services, and install only the minimum applications (and plugins) required for proper operation of your operating system, database, and application server. Uninstall and/or disable all unused applications and services (including non-essential operating system services), and limit the number of additional applications and plugins installed to the minimum necessary to run your dotCMS server and applications.

Limit Access Points with a Firewall

You should close off as many ports as possible on your server, to limit the number of potential access points which could be exploited by an attacker. Install a firewall or enable your operating system's built-in firewall, and make sure the firewall is configured to close off as many access points as possible.

Use and Maintain Anti-Virus Software on Endpoints

It is important to understand that anti-virus software on your server can interfere with both the operation and performance of your server software and dotCMS; therefore, dotCMS recommends that you do not run anti-virus software on your server.

However it is important to run anti-virus software on all endpoints which can access your server from within your firewall. Therefore it is recommended that you ensure that up-to-date anti-virus software runs on all your endpoints, including all client machines that access the dotCMS back-end.

If possible, use anti-virus software on endpoints to:

• Monitor inbound and outbound traffic for malicious payloads.
• Scan uploaded and downloaded files.
• Scan for malicious software behavior.

Restrict Server Permissions

The dotCMS server accesses files within your dotCMS installation folder on your server. However, depending on your configuration, content and permissions, it may be possible (and desirable) for dotCMS to attempt to access other folders outside the dotCMS installation folder.

To ensure that sensitive system files can not possibly be accessed unintentionally, it is recommended that the user account which runs dotCMS be set to a non-root account (non-Administrator on Windows), and that the user account which runs dotCMS only be given access to the specific directories you wish for dotCMS to be able to access.

In addition, the files in the dotCMS directory are critical to the operation of dotCMS, and should not be accessible except to authorized users. Ensure that the owner and permissions of the dotCMS installation folder are set properly to prevent unauthorized access.

Remove All Sensitive Files from the ROOT Folder

All files in the dotCMS root folder (/dotserver/tomcat-X.x.xx/webapps/ROOT in the default distribution) may be downloaded by unauthenticated users. This is intentional, since it allows you to make files available for download by simply copying them into the root folder on the server. However you must ensure that you do not have any files in this folder that you do not want to be downloadable by an unauthenticated user. Specifically:

• If you have created a customized starter.zip file, remove it from the dotCMS root folder.
• Do not add any executable files (e.g. .jsp files) to the root folder, unless you want unauthenticated users to be able to execute them.
• If you want to make any files available for download only by authenticated users, do not copy them into this folder.
  • Instead, upload the files into the dotCMS folder tree using the Site Browser or dotCLI.

Disable Access to the AWS Metadata Endpoint

If you are running dotCMS on an AWS server, prevent dotCMS from having access to the Amazon ECS Task Metadata Endpoint.

For example, perform a routing table modification on server startup to restrict access to this endpoint, similar to the following:

iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP

Implement Strong Database Security

Limit Access to Database Accounts, Files, and Folders

Many of the best practices which apply to configuring your server also apply to installing and configuring your database. Although the specific steps to take vary based on your database and how you intend to use it, consider the following guidelines:

• If there is a default database administrator account, disable it and create a new administrator account with a new unique name.
• Use strong passwords for all database users.
• If there are any database services, applications, or plugins which are not used or needed (such as replication), disable or uninstall them.
• Close off open ports for database services or features which are not used.
• Install the database in a folder which can not be accessed by inappropriate users.
• Limit the permissions of the user account used to install the database to the minimum necessary.

Control Database Permissions

It is also important to properly control access within the database itself:

• Use the inherent security of your database to ensure that only authenticated users can access the database.
  • Disable all default or built-in database users.
    • Create new database user accounts with non-standard names for all your database users.
  • Use secure passwords for all database users.
• Do not include any strings in SQL queries that originate with user input.
  • Please see Sanitizing SQL Queries, below.
• Limit all database users to the minimum access required.
  • If any of your code or pages requires access to run queries against any database (including, but not limited to, the dotCMS database), create a database user account with very limited permissions, and run the queries with this limited user account.

In addition, if you access the database from within any of your application code or plugins, make sure to follow secure database coding practices, especially Sanitizing all SQL Queries.

Configure Databases Securely

The context.xml contains configuration settings for your dotCMS database, and all other databases which you wish to access using the dotCMS SQL Tool. This file contains login information for each database, and access to this file should be strictly controlled.

In addition, it is important that if you run dotCMS on Windows (or any other operating system which does not have a case sensitive filesystem), you must disable the allowLinking flag in your context.xml file.

• Enabling this flag on Windows or other inappropriate operating systems disables case sensitivity checks, allowing JSP source code disclosure and other potential security problems.
• For more information, please see the Apache Tomcat Configuration Reference.

Maintain the Latest Software Versions and Patches

Operating System and software vendors regularly release updates which include security enhancements and fixes for potential security issues. Therefore it is crucial that you keep all your software up to date to ensure you have protection from known security vulnerabilities.

In addition, if you are using Anti-Virus software, ensure that both the software version and the signature files are updated as frequently as possible.

The following links lead to sites which provide security information and/or security patches for many of the different platforms dotCMS works with.

Always Upgrade to the Latest dotCMS Release

Each new releases of dotCMS may include fixes for security vulnerabilities discovered in the dotCMS code base. This may include vulnerabilities listed on the Known Security Issues page, vulnerabilities or potential vulnerabilities discovered and fixed internally, changes to mitigate or prevent known security vulnerabilities in operating systems or other software, and security enhancements meant to prevent potential exploits even if no actual vulnerability has been found or demonstrated.

Therefore, for maximum security it is important that you always upgrade to the most recent dotCMS release as soon as possible. If for any reason you are not able to upgrade to the latest dotCMS release, please contact dotCMS Support and ask if there are any security hotfixes available for the version of dotCMS you are using.

Note: dotCMS automatically and proactively upgrades all dotCMS Cloud customers to the latest dotCMS version immediately after each new release.

Keep Up-to-Date with Third Party Security Fixes

Ensure that you maintain the latest security fixes for all third-party software run on your dotCMS server, including elements of the server platform such as the operating system and database, and any third party packages you've integrated into dotCMS through static or dynamic plugins, SQL queries, or other integration methods.

To assist you in finding and maintaining current security levels on your dotCMS server platform, the following is a partial list of sites which provide up-to-date security information for major operating systems, databases, application servers, and Java versions supported by dotCMS.

Operating System Security Sites

The following sites provide security information and updates for the most common operating systems used with dotCMS:

Database Security Sites

The following sites provide software updates and security information for databases supported for dotCMS production sites:

Note: The H2 database is not included here because it is NOT intended for production use. Neither the performance nor security characteristics of the H2 database are appropriate for production systems.

Application Server Security Site

The following site provides security information and updates for the application server supported by dotCMS:

Java Security Sites

The following sites provide security information for the Java Virtual Machines recommended for use with dotCMS:

Ensure Back-End Users Have Secure Browser Software

Although you can not control the browsers used by external users to access your site, it is important that any users who can access the dotCMS backend use secure browser software when logging in to dotCMS. Therefore, as much as possible make sure your developers, administrators, and content creators are running the latest versions of their browser software, to ensure they have the most recent security patches.

The following sites provide security information and updates for the most popular browsers used with dotCMS:

Configure dotCMS for Maximum Security

The following sections outline some of the most common areas of dotCMS configuration that should be considered when implementing security for your dotCMS site. Not all of these configurations will make sense for all sites; however you should consider each of these and understand the implications and potential vulnerabilities if you choose not to implement them.

Increase Login Security

For most servers — with possible exception given to a receiving server in a Push Publishing configuration — the use of a Single Sign-On (SSO) solution, such as SAML (through Azure or another identity provider) is recommended.

Configure SSL

SSL establishes an encrypted link between the client (browser) and server (dotCMS). SSL provides an important layer of security by ensuring that data transferred between the server and browser can not be intercepted and read or spoofed. Configure dotCMS to use SSL and then configure dotCMS to require SSL for all back-end logins.

Configure JWT to Only Allow Access Through HTTPS

By default, dotCMS allows regular HTTP access for back-end logins. To improve login security, you may configure dotCMS to only allow HTTPS access for JWT authentication (back-end login) by changing the value of the json.web.token.allowhttp property to false:

json.web.token.allowhttp=false

For more information on how to configure JWT authentication properties, please see the Authentication Using JWT documentation.

Limit Access to Code Files and Folders

Configure permissions within dotCMS to limit both read and write access to any code files to only those users and Roles that must have access to those files. This includes Velocity files (.vtl), Java Server Pages (.jsp)., JavaScript (.js), and any other code files that may be used on your site.

Note, however, that code files must still be viewable by any users who display a page in which that code file is included. For example, if a page on your front-end site includes a Velocity (.vtl) file, that file (and the folder where it is located) must have View permissions for the CMS Anonymous user; if the code file is not viewable by a non-authenticated user, then the code in that file will not be read when the user views that page, and the page may not display properly.

Even when your code files must be viewable by the CMS Anonymous user, it is strongly recommended that you:

• Separate code files which must be viewable from your front-end from those that only need to be viewable by authenticated users.
  • This makes it easier for you to manage the different permissions required for these two sets of code files.
• Strictly limit write access to both the files and the folders where any code files are stored, regardless of where those code files need to be viewed.
  • This is true both for code files viewable on the front-end and code files that are only visible to authenticated users; write access should be strictly controlled to limit both intentional and unintentional execution of unauthorized code.

Implement Secure Push Publishing

Push Publishing is designed to enable strong security, to ensure that only authorized users and servers may send content to remote servers. There are three levels of Push Publishing security; for maximum security, it is strongly recommended that you implement all of them, especially for any servers which are public-facing (located outside of your firewall).

1. Restrict Push Publishing Authorization

When creating a Push Publishing Environment, you must specify which users are allowed to push to the environment. It is recommended that you to carefully control push publishing authorization, to reduce the chance that unauthorized content is pushed to the receiving server (even unintentionally).

• Limit push authorization for each push environment to the minimum number of users necessary.
• Implement Mandatory Workflow Schemes to limit the users and Roles who may perform the Push Publishing action on content of specific Content Types.
  • If you assign a Mandatory Workflow Scheme to a Content Type, then for any user to be able to Push Publish content of that Content Type, they must have authorization for both the publishing environment and the appropriate Workflow Action(s).

2. Limit User Access and Permissions to Receiving Servers

To prevent both potential security issues and potential content conflicts (e.g. the creation of the same content on both the sending and receiving servers), it is strongly recommended that you strictly limit permissions of user accounts on the receiving server.

• Do not use the same user accounts on the sending and receiving servers.
  • Do not create user accounts on the receiving server for all users with accounts on the sending server.
  • Even for users with accounts on both servers, create different user accounts on the receiving server.
• Create different Roles on the receiving server than on the sending server.
  • This reduces confusion and ensures that permissive rights on the sending server are not copied to the receiving server.
• Significantly limit the Permissions available to the Roles on the receiving server.
  • Specifically, do not grant permissions to allow content creation and modification on the receiving server.

Note that although you may Push Publish user accounts from the sending server to the receiving server, you may not push Roles or Permissions. This is intentional, as in most cases you will want to grant greater permissions on the sending server than the receiving server, and this restriction ensures that you must manually determine and configure the Roles and Permissions used on the receiving server.

3. Use Strong Authorization Keys

When configuring each Push Publishing connection, you may configure an Authorization Key which is used by the receiving server to authenticate that content is being sent from the correct server. It is recommended that you implement strong authorization keys to help ensure that your sending server can't be “spoofed” (impersonated) by another server in order to send unauthorized content to your receiving server.

• Implement authorization keys for all receiving servers in all Push Publishing environments.
• Use character/composition requirements similar to those implemented for passwords.
• For an additional level of security, create different authorization keys for each receiving server (even when multiple receiving servers are configured as part of the same Push Environment).

Disable Features with Potential Security Risks

Ensure XSS is Disabled

By default, XSS is disabled for all classes in dotCMS except the following 3 classes:

• com.liferay.portal.model.Portlet
• com.liferay.portal.model.PortletPreferences
• com.liferay.portal.model.Skin

The XSS configuration settings are contained in the portal.properties file (/dotserver/tomcat-X.x.x/webapps/ROOT/WEB-INF/classes/portal.properties). To ensure XSS is disabled in dotCMS, please review the following section of your portal.properties and portal-ext.properties files and verify that the settings match the following (default) settings:

    # Set the following to true to ensure that all persisted data is stripped of
    # XSS hacks.
    #
    xss.allow=false

    # You can override the "xss.allow" setting for a specific class by setting
    # the property "xss.allow" plus the class name.
    #
    xss.allow.com.liferay.portal.model.Portlet=true
    xss.allow.com.liferay.portal.model.PortletPreferences=true
    xss.allow.com.liferay.portal.model.Skin=true

Note:

• These values are set by default settings, so you do not need to make any changes unless you have already modified these properties.
• It is strongly recommended that all changes to the portal.properties file be made through a properties file extension.

Ensure the XSS Prevention Filter is Enabled

BY default, dotCMS blocks all access to all files in the /html and /dotAdmin folders unless dotCMS is sent a valid referer or Origin header.

The Origin Header is checked first and if it is not present, dotCMS will fall back to the referer header. For a request to be valid, one of the following must be true:

• The Origin/referer is the same host name as the request URL.
• The Origin/referer header has a value equal to the Name or Alias of another Site on the same dotCMS instance.
• The Origin/referer header has a value equal to the “Portal Url” as defined on the Configuration Screen.
• The request is for a CSS file (e.g. *.css).
  • This must be allowed because CSS @import statements do not set a referer.

This feature can be disabled, and the paths which are blocked can be overridden by adding the XSS_PROTECTION_ENABLED=false and XSS_PROTECTED_PATHS properties to the system configuration.

Example:

XSS_PROTECTION_ENABLED=false
XSS_PROTECTED_PATHS=\\A/html/,\\A/c/,\\A/servlets/

If you have a case where you need to allow access to an administrative file or folder by requests that do not meet these requirements, you can add the IGNORE_REFERER_FOR_PATHS property to system configuration, and provide a comma-separated list of paths to ignore (e.g. allow access to). The paths listed in this property may end with an asterisk (*) to ignore (enable access to) all paths which begin with the specified path.

Example:

IGNORE_REFERER_FOR_PATHS=/html/common/css.jsp,/html/my-plugin/*

Finally, care should be given to private subnet access. There are two configuration properties to consider:

ALLOW_ACCESS_TO_PRIVATE_SUBNETS, if set to true, completely disables all checks on private subnet access; REMOTE_CALL_SUBNET_BLACKLIST is only considered while ALLOW_ACCESS_TO_PRIVATE_SUBNETS is false.

As such, there are three basic postures on private subnet access that these properties facilitate:

• Strict: By leaving both properties unconfigured, the out-of-the-box behavior of dotCMS is to block private subnet access.
• Lax: By setting ALLOW_ACCESS_TO_PRIVATE_SUBNETS=true, the blacklist variable is bypassed, and all private subnet traffic is allowed.
• Custom: By leaving ALLOW_ACCESS_TO_PRIVATE_SUBNETS=false and fine-tuning REMOTE_CALL_SUBNET_BLACKLIST with a comma-separated list of explicitly blocked subnets, you can permit the use of specific private subnets according to need.

As always, prepend DOT to the configuration property names — e.g., DOT_REMOTE_CALL_SUBNET_BLACKLIST — when configuring them via an environment variable.

To ensure maximum protection from XSS and CSRF vulnerabilities, ensure that:

• The XSS_PROTECTION_ENABLED property either does not appear in the system configuration settings, or is set to true.
• The XSS_PROTECTED_PATHS property either does not appear in the system configuration, or contains all of the following paths at a minimum:
  • /html/
  • /c/
  • /servlet
  • /servlet/
  • /dottaillogservlet
  • /dwr/
  • /dotajaxdirector
  • /dotscheduledjobs
  • /jsontags/
  • /edit/
• The IGNORE_REFERER_FOR_PATHS property does not contain any paths which might contain sensitive files which could be exploited by XSS or CSRF attacks.

Verify that the Elasticsearch Native REST API is disabled

dotCMS Elasticsearch REST API

dotCMS provides a secure Elasticsearch REST API to perform Elasticsearch queries against the dotCMS content store. The dotCMS API respects dotCMS Permissions, allowing users to safely perform Elasticsearch queries against your dotCMS content store, both from within dotCMS and from external applications.

Native Elasticsearch REST API

Elasticsearch also provides a native REST API; however the native Elasticsearch REST API is not secure, as it allows users to add, modify, or delete your dotCMS Elasticsearch indexes, which could corrupt or completely disable your dotCMS site.

Because of the potential security vulnerabilities it presents, the native Elasticsearch REST API is disabled by default in dotCMS, and it is strongly recommended that you leave it disabled except in the following specific circumstances:

• You have a need to access the native Elasticsearch API directly rather than using the dotCMS Elasticsearch API (for example, to integrate a third party application, or for system management and monitoring applications running on your internal network).
• Requests to the native Elasticsearch API are performed only from within your internal network.
• Access to the native Elasticsearch API port from outside your network is blocked by a strong and up-to-date firewall.

To ensure the native Elasticsearch API is disabled, verify that the following configuration properties in the elasticsearch.yml file (in the WEB-INF/elasticsearch/config folder) are disabled (as shown below):

    http.port=9200
    http.host=localhost
    http.enabled=false
    http.cors.enabled=false

Note:

• It is strongly recommended that all changes to the elasticsearch.yml file be done through a properties file extension.
• It is extremely important that the http.cors.enabled property be disabled unless you are embedding the native Elasticsearch API call in another web app (cross origin).
  • Enabling this property provides “unpermissioned” access to the content index/store, allowing unauthenticated users permission to freely add, modify or remove your Elasticsearch indexes.
  • You should never embed the native Elasticsearch API in any publicly-accessible web application unless you have built a highly secure web firewall in front of the application limiting the operations that can be performed.

Prevent REST API Access by Unauthenticated Users

Most REST API endpoints provided by dotCMS do not allow access by unauthenticated users. However some endpoints which only retrieve data may be accessed by unauthenticated users. When an unauthenticated user accesses any dotCMS REST API endpoint, they are treated as the CMS Anonymous user, which means they may only retrieve information which has been permissioned to be accessed by unauthenticated users (such as data displayed on the front-end of your Site).

Note: By default, anonymous users may read, but not write, from content APIs. However it is recommended that you check and explicitly set these properties to ensure anonymous access is properly restricted.

Ensure that Limited Access Users Do Not Have Back-end Access

Users may be given access to either or both of the front-end of your site and the back-end configuration interface. In addition, user accounts may be assigned API Access Keys to allow access to the REST API.

It is best practice to separate user accounts that may directly login to the back-end UI from both accounts that are used for accessing the REST API and from user accounts with access to front-end forms.

• To set up a User account that only has access the REST API, select the user in the Users Tool, and ensure that the user does not have Front-end User or Back-end User access, and then create an API Access Key for that user.
• To set up a User account that only has access to front-end forms, select the user in the Users Tool, and ensure that the user has Front-end User access, but does not have Back-end User access.
• To set up a User account that only has access to the back-end UI, select the user in the Users Tool, and ensure that the user has Back-end User access, but does not have Front-end User access.

Restrict Unauthenticated Access to ALL REST APIs

To restrict access to all REST API endpoints by unauthenticated users - preventing unauthenticated users from accessing all data (even data which is permissioned for read access by the CMS Anonymous user) - set the following system property:

REST_API_REJECT_WITH_NO_USER=true

Restrict Unauthenticated Access to Content APIs

To prevent unauthenticated users from having both read and write access to only content APIs (including the Content API, Workflow API, etc.), but still allow anonymous access to other APIs, set the following property in the system variables:

CONTENT_APIS_ALLOW_ANONYMOUS=false

Restrict Unauthenticated Access to Write Content

To prevent unauthenticated users from having write access to content APIs (including the Content API, Workflow API, etc.), but still allow anonymous read access to content APIs and access to other APIs, set the following property in the system variables:

CONTENT_APIS_ALLOW_ANONYMOUS=READ

Strictly Control Access to Static Endpoints

Configure your Push Publishing Static Endoints to restrict access to all of the following:

• A specific AWS user account.
  • Create a separate AWS user account specifically for dotCMS.
  • Limit the user account to the minimum rights needed for dotCMS to publish static content (and, if necessary, create new buckets matching the AWS S3 bucket variables).
• A specific bucket or set of buckets.
  • Use a combination of prefixes and wildcards in the AWS S3 Access Control List (ACL) to limit the buckets the AWS user account has rights to.
• A specific IP address or range of IP addresses.
  • The AWS S3 ACL allows you to specify that content can only be written to a bucket from a specific source IP address or range of source IPs or specific HTTP referrer. Ensure that you restrict access so that only the IP address of your dotCMS authoring/UAT server can write content to your AWS S3 bucket(s).

Manage User Accounts Securely

Improve Password Security Requirements

The dotCMS distribution is configured by default with minimal security to ease installation, evaluation, and testing of the dotCMS starter site. Therefore the default values of all password validation properties are set to the minimum security levels.

Therefore it is strongly recommended that you increase the password security settings for your site before publishing it.

For instructions on how to change password requirements, please see the Password Security Configuration documentation.

Integrate with a Third-Party Authentication System

Different authentication systems provide different options for improving authentication security, including password requirements, authentication methods, handling of authorization tokens, speed of updates and fixes, and more. dotCMS provides plugins which allow you to integrate with several industry-wide authentication frameworks, including Oauth and SAML (please contact dotCMS Support for information on SAML integration).

Due to the wide adoption, significant development resources, and extensive validation they receive, third party authentication frameworks are generally able to be configured for higher security than the built-in dotCMS back-end authentication methods. If your dotCMS server is accessible from outside your network, it is recommended that you integrate with one of these external frameworks to take advantage of the more full-featured options they offer.

Require Two-Factor Authentication

Many third-party authentication systems provide the ability to enable Two-Factor Authentication to increase user login security. If your dotCMS server is accessible from outside your network, it is recommended that you implement two-factor authentication for all linked user accounts.

Deactivate Default Administrator Accounts

The dotCMS starter site contains two default administrator accounts with full access to your dotCMS system: Admin User and Admin2 User.

It is strongly recommended that you:

1. Create new administrator accounts with different user names and passwords from the default accounts.
2. Deactivate the default accounts.

This ensures that no one outside your organization knows the account names of your administrator accounts, preventing potential brute force password attacks against these accounts.

Deactivate Unused User Accounts

Ensure that all user accounts are deactivated immediately as soon as the users are no longer with your organization, or no longer need access to dotCMS.

One way to help ensure unused user accounts are deactivated is to integrate dotCMS with your enterprise user authentication using CAS. This ensures that authentication in dotCMS automatically receives and reflects changes to your enterprise users and permissions.

Limit User and Role Permissions

Configure all users and Roles with the minimum permissions necessary for users to perform their work in dotCMS.

• Configure permissions to give Roles only the minimum necessary permissions to perform their required tasks.
• Assign each user only the minimum Roles required for the user to perform their work.
• Limit the number of users with full administrative privileges.
• Maintain permissions separately for different dotCMS servers.
  • Ensure that permissions to change backend configuration and code are limited to developers.
  • Ensure that permissions to change public-facing servers are limited to a small set of users or Roles.
• Implement a Workflow that ensures content is reviewed before being published to your server.

Use Secure Coding Practices

Use secure coding practices to ensure that vulnerabilities are not introduced into your application through plugins or Velocity or script code on your site.

The following is a short list of important coding security practices. For a more complete list, please see the SANS SWAT (Securing Web Application Technologies) Checklist.

• Define security requirements.
• Educate developers about the security requirements.
• Conduct design reviews and code reviews.
• Don't Hardcode Credentials.
  • Never store credentials within the application code.
• Perform security testing.

In addition, pay special attention to the following sections in all your application and plugin code.

Guard Against Malicious User Input

As a general rule, it is best to assume that all user input you receive is not safe. It is easy for malicious users to enter potentially dangerous content, and since user input is often a normal function of your site, it is very difficult to identify when malicious input is being entered (or has already been entered). Follow these guidelines to help protect your site against dangerous input (whether malicious or unintentional):

• Filter user input to check for HTML tags (which might contain scripts) and Velocity code.
• Never display unfiltered user input.
  • HTML encode any user input before displaying it, to ensure any harmful code will not be interpreted and run by the browser.
• Never pass unfiltered user input to searches, database queries, internal methods, or external program calls.
• Never store unfiltered user input in a database.
• Do not rely on or trust the safety of information in the HTTP headers (Request, Response and Session).
  • Information in these headers, including user agent information, location information, and more can be spoofed.
  • Implement filters and other safeguards for cookies, query strings, and code that checks the values of these headers.
• Do not store or display sensitive information anywhere it may be accessible from the browser (such as displayed on pages, in hidden fields, or in cookies).
  • For example, passwords should never be stored in a cookie.
• Do not allow users to enter a path to any file in your application or on your server.
  • This helps prevent users from getting access to any other folder on your server (where they would have the permissions of the user dotCMS is installed under - see Server Permissions, above).
• Whenever possible, validate user data using a “whitelist” approach.
  • Implement validation on each user input field.
• When verifying or filtering user input, use a white list approach (rather than a blacklist approach).
  • Explicitly define what you will accept, and filter out everything else.
  • Do not attempt to identify or exclude malicious input.
    • It is nearly impossible to anticipate all possible malicious values, especially as your application and potential security issues change over time.

Sanitize SQL Queries

The dotCMS code has been explicitly sanitized to prevent SQL injection attacks. However if you perform any SQL queries in your Velocity code, it is possible for you to introduce vulnerabilities to SQL injection attacks if you are not careful.

The best way to prevent the possibility of SQL injection attacks in your Velocity code is to use SQL Parameter Queries. This ensures that all user entered data is sanitized and sent to the database as a parameter, so that it is not interpreted by the SQL parser and thus can not expose your code to SQL injection vulnerabilities.

Control the Use of Cookies

Cookies which store sensitive information can provide an attacker with the information they need to compromise your server or site. Therefore it is important that you are careful about what information you store in cookies, and how that information is stored.

• Do not store any sensitive - or even potentially sensitive - information in cookies.
  • For example, never store a password in a cookie, even temporarily.
  • As a rule, do not keep anything in a cookie that, if spoofed or decrypted, can compromise your site or server.
    • Instead, store the information on a location in the server that requires authenticated access, and keep a reference to that location in the cookie.
  • If you really must store some potentially sensitive information in a cookie, make sure to encrypt it.
• When possible, don't make cookies permanent.
  • Set cookie expiration dates the shortest practical time.
• If possible, set the Secure and HttpOnly properties on all cookies to true.
  • To ensure that the HttpOnly property is set on all cookies automatically, set the COOKIES_HTTP_ONLY property in the system variables to true.
• Set cookie domains and paths correctly.
  • The domain and path should be set to the most restrictive settings possible.
  • Whenever possible, do not use wildcard domain scoped cookies.

Limit the Potential for DoS/DDoS Attacks

DoS (Denial Of Service) and DDoS (Distributed Denial of Service) attacks are one of the most common attacks against web sites and applications, and are very difficult to fully protect against without specialized hardware and software. However there are many types of [D]DoS attacks, and you can help minimize the impact of certain types of these attacks by following these guidelines:

• Test and/or limit the size of all user supplied data.
  • Test the size of user input before using or storing it.
  • Restrict the size of file uploads, if appropriate.
  • Consider limiting the frequency of user requests.
• Test and/or limit the size of all user-requested output.
  • Put size limits on the results of all widgets, ES Queries, and database queries originated from user requests.

Regularly Review System Logs

When a malicious or unauthorized user attempts to access or take malicious action against your system, they usually take actions which leave some kind of trace in the log files. Therefore it is important to review system logs as frequently as practical, both so you can recognize normal and abnormal log file messages, and detect any unauthorized attempts to access your system as quickly as possible so you can take addition precautions if necessary.

• Regularly review the Security log
• Periodically review other system log files
• Investigate unusual logging or user behavior
  • Unsuccessful login attempts
  • Unusual login locations
  • Attempts to login to individual's accounts while they're already in use

Review Additional Security Resources

The following is a list of some additional resources which you may find of value in implementing and evaluating the security of your dotCMS sites.