Introduction
This security checklist was created by the Liferay Team to offer another measure of protection for customer projects. The checklist covers best practices for Liferay PaaS. For Liferay PaaS security considerations and best practices, please refer to the Liferay Help Center.
Disclaimer: The items in this checklist are suggested best practices and it will be the end-user’s responsibility to implement.
General Items |
||
Item | Description |
Notes |
Repository |
Migrate the default GitHub repository to a private GitHub/GitLab/Bitbucket repository owned by your organization. The default GitHub repository is provided as a starter template available for 10 days and for privacy regulations it should never be used to commit code owned by your organization. |
|
Security Patches |
Apply DXP and Liferay PaaS security-related fixes as soon as they are released. DXP docker images are published here. Liferay PaaS Service Change Logs are published here. |
|
Commits to Repository |
Care should be taken that any licenses, credentials, and secrets are not accidentally committed to the repository. Remember Liferay PaaS environments do not require you to supply a license. The enterprise Liferay DXP license is included as part of the deployment process. |
|
Code Scans |
Liferay PaaS provides a CI pipeline for builds. Automate and enforce cleaner and safer code practices by customizing the pipeline to run code scans on every build. |
|
Elasticsearch |
Enable Elasticsearch security features by setting the |
|
Account Management |
||
Item | Description |
Notes |
Single Sign-On |
Liferay PaaS can integrate with any SAML 2.0 compliant Single Sign-On Identity Provider to authenticate users to the Liferay PaaS platform. You may set up Multi-factor authentication for development and IT team members through any Identity Provider that supports MFA. |
|
Default Portal Account |
If you deploy the out-of-box build of the Liferay portal to your production environment, you should be aware that the default user test@liferay.com is available for sign-in with a weak password ‘test’ and must be changed as soon as possible. Also, disable the creation of new accounts. The dev environment has an extra layer of authentication at the webserver layer. |
|
User Activities |
Perform a periodic audit, at least quarterly, of user activities, in each Liferay PaaS environment as well as DXP portal. |
|
Team Members |
Audit Team Member access periodically, at least quarterly, making sure to go through each environment and delete inactive team members. The same applies to DXP roles and assignments. |
Network Controls |
||
Item | Description |
Notes |
Egress IP |
If Liferay DXP accesses your private network, the Liferay Cloud cluster egress IP is available to be whitelisted. |
|
Blacklisting or Whitelisting IPs |
You can blacklist IP addresses from certain regions by configuring a Deny List in the Nginx web server configuration. For greater control and if the IP addresses of your users are known, you can set up an Allow list instead. |
|
Public Endpoints |
Although possible, and available for extreme backdoor scenarios, it is not a recommended practice to expose database endpoints or other service endpoints to the Internet as this bypasses the DDoS protection from the HTTPS load balancer. |
|
Rate Limiting |
Nginx can be configured to throttle requests from reaching the Liferay service. It is recommended that customers monitor their traffic patterns and acceptable rates of access to configure these settings. |
|
DNS |
Ensure that your DNS provider implements best practices related to DNS security. |
Backups |
||
Item | Description |
Notes |
Backup download |
Backups in the Liferay PaaS are always encrypted at rest and in transit. However, if you download backups to a local machine you should ensure that you have mapped out your data flow so you can be in compliance with any regulations that you are required to adhere to. |
|
PII Sanitizing |
Using production data in non-production environments is helpful for debugging but does pose risks. When restoring backups into non-prod environments - implement scripts for PII data masking. |
HTTP Layer |
||
Item | Description |
Notes |
Ciphers |
Depending on your compliance requirements you may request an increase in the restrictions on the cipher policy for SSL to reduce the set of SSL features allowed. By default, the policy is to allow a broad set of clients, including clients that support only out-of-date SSL features, to negotiate SSL. |
|
CORS |
Cross-origin resource sharing (CORS) can allow requests from an outside domain. It is recommended that you configure your Liferay DXP instance to allow only required domains to interact with your web application. |
|
Content Security Policy |
Content Security Policy (CSP) prevents malicious resources from being loaded by a web browser. The |
|
URL Redirects |
Ensure that HTTP to HTTPS redirects first redirect to a secure version of the same site to prevent man-in-the-middle redirects to malicious sites. Ensure that redirects never forward to HTTP. URL redirects are configurable via the nginx configuration file. |
|
HSTS |
HTTP Strict Transport Security (HSTS) header ensures that, after a user's initial visit to the website, they will immediately connect to the HTTPS website. The |
|
Web Browsers |
Nginx can be configured to verify the user agent header and block access to the site from outdated web browsers. |
|
Secrets |
||
Item | Description |
Notes |
Storage and Rotation |
Save secrets in a safe storage and rotate them regularly. |
|
Disaster Recovery Master Token |
The master token used in DR configuration should be created as a secret. |
|
Repository Access |
The Private Access Token for your git repository (GitHub/GitLab/BitBucket) should be created as a secret. |
|
Dynatrace |
In case your Liferay PaaS subscription includes Dynatrace, the Dynatrace Tenant and Token should be created as a secret. |
|
SSL Certificates |
If you’re installing custom SSL certificates, create the key and certificate properties as secrets. |
|
Dev Environment Access |
The dev environment portal access is protected by default credentials which are shared in the provisioning email. You should customize the dev environment Nginx configuration and set your own credentials. To avoid committing to the repository implement the credentials as a Secret. |