Quick Tips for Liferay Hardening

The basic bundle that liferay provides with different Application servers are pretty straight forward to install and setup. So that using them one can easily get started with a working liferay portal. Actually the default settings that liferay provides is ideally for developers. Now the question is, whether it’s also safe to start using the same thing for production as well? Well the answer is no, because it would not be secure to use that default settings of liferay bundle. That doesn’t mean that Liferay is not secured, it simply means that one should not deploy liferay with default settings and assume that it’s secure. Here we would try to accumulate points using which we can harden our liferay’s security for production. Now when I say security or securing the server by restricting access to certain things in liferay, it might not be right to generalize these points. What adds security for one ruins a feature for somebody else. Over here I would try to point out certain areas or options that liferay provides. 


It’s a good practice to keep a web server infront of Tomcat/jboss bundled with Liferay. Let’s call it Apache front servers (for example Apache httpd). Another good practice is to use the staging live feature of Liferay, so that content can be easily published to the production. But it also depends on the need and purpose of the product or project. The advantage of using this feature is to keep the staging environment to internal network and the live environment for external network. In this way lot of things can be blocked for the Live environment but can be open in the staging environment. For this blog we will be assuming that we are following the above assumptions.

1.     Default admin user: The default admin user needs to be deactivated or removed and a custom new admin user should be created.

default.admin.* property in file needs to be checked.

2.     Default Pages or Urls blocked by Front server: Undesired pages can be blocked by Apache Web Server (Apache Front Server). With this technique the pages can be still accessed from inside of the client network. For example : Live portal admin pages can be accessed from inside of client network to carry out some crucial administrative tasks (for example re indexing search) but are completely blocked for outside world.

Undesired pages can be blocked in the portal. This is done by disabling the feature for some roles with permissions or disabling the page completely with portal properties.

For example:  There can be more such urls, this is just a starting point, based on the requirement urls can be blocked.




Purpose of the Page





Liferay main servlet urls (e.g Liferay login page)

Blocked by front servers from outside of client network. In config file similar entries can be added:

RewriteRule ^.*/c/.*$ /XYZ-theme-theme/html/e404.html [L]




Liferay external APIs

Blocked by front servers from outside of client network.




Public user personal site pages (Depends on the requirement)

Blocked by front servers from outside of client network.




Private site pages including control panel pages. The control panel pages are used for content management and portal administration.

In staging the control panel access is needed for content management and portal administration tasks.


Apart from default pages there are non-unique pages (different site specific page) as well. Different way of accessing pages:

·       Using web/{site name}/{page name} – needed for sites which does not have virtual hosts name. However the main site should not be used this way.

·       Using layout Ids in URL: For example /c/portal/layout?p_I_id=<plid>, where <plid> is the layout id. This shall be blocked from the front server. (rule that blocks all c/.* pages )

·       Using /group/{site name}/{page name} – None of the pages should be accessible this way.

·       Using locale or language URL prefix: For example: /sv_SE/web/{site_name}/{page_name}, These urls shall be blocked /redirected from front server.

3.     Default pages or sites - blocked by Portal: Depending on the requirement the Personal or Public site for the user can be disabled using These are the properties using which it can be disabled :



Apart from this site the default site “/web/guest/” should also be disabled or removed from the portal.

4.     Default Portlets: There is a group of default portlets that can be accessed from any public page in the portal by appending proper parameters to the end of the URL. For example, login portlet can be accessed in the following way.


All portlets must not be accessible from the public in this manner. The prevention shall be done in the following two ways:

a.     In front servers by redirecting all requests that have p_p_id=x in the URL, where x portlet id which is not whitelisted.

b.     Disable undesired portlets in the live portal completely by removing their definition in portal’s liferay-portlet.xml (create external plugin with liferay-portlet-ext.xml file). In the staging portal, the removal of portlets is not necessary.



5.     Remote Services:  Undesired Remote services can be disabled with invoker IP filtering so that the service APIs cannot be called outside of the local machine. Our suggestion is to disable all external APIs with this filtering mechanism in the live portal. In addition, APIs that are not needed in staging either should be disabled there as well.


Disabled/Enabled in staging

Disabled/Enabled in live

Purpose of the API


 Axis Servlet

Depends on requirement


Liferay’s default SOAP web service

Setting properties



Liferay Tunnel Servlet



Liferay Tunnel Servlet

Setting properties




Spring Remoting Servlet



Spring Remoting Servlet

Setting properties



JSON Servlet



JSON Servlet

Setting properties



JSON Web Service Servlet



Liferay’s default JSON web service

Setting properties



WebDAV Servlet



WebDAV provides functionality to create, change and move documents in document library on a remote server.

Setting properties

  • webdav.servlet.hosts.allowed
  • webdav.servlet.https.required

6.     Disabling default servlets: Liferay offers a number of servlets that are by default open to be used. It should be the policy that any servlet that is not needed, is disabled/removed from the portal. Liferay support instructions for disabling servlets. For example: Disabling it through file 

# The audit filter populates the AuditRequestThreadLocal with # the appropriate request values to generate audit requests.    

#     com.liferay.portal.servlet.filters.audit.AuditFilter=false

    Apart from the servlet filters there are several other SSO hooks which are present in the portal properties file. Those     are required to be disabled or removed from there, if those are not getting used.

    7.     Struts Action:  Struts actions could be handled in one of the following ways (to be decided).


a.     Undesired struts actions can be disabled in the portal by deleting them from struts-config.xml file

b.     Undesired struts actions can be blocked by the front servers with regular expression type of filtering and redirecting

e.g. if URL contains a string "/portal/login" then the page is redirected to e.g. front page of the site

c.     Disabling corresponding portlets in the portal.

Full list of struts actions can be found here The disabling can be done by modifying this file.

Note: According to Liferay support "Modifying this file by deleting some of the actions is not advised at all, and can cause the crush of your portal! You can override or add different struts-actions, but deleting them is a dangerous maneuver".

   8. People working with liferay we all know how important this file is when we think of configuring    our portal. There are more than 1000 odd entries in this property file. Going through all of them here is not an option.      One can check details of this property file in a more readable format from here. We will try to share some of the         important properties related to security over here:

  • Jdbc.default.password: Password kept in clear text is not a good practice for production environment. JNDI name can be used to connect to a database. is the required key.
  • *.auth.enabled: This determines what kind of login we are allowing on our portal. It can be ldap, OpenID, Facebook etc.  For example: ldap.auth.enabled
  • Password.encryption.algorithm: It’s better to use a password encryption algorithm which would be tough to break. Example: SSHA
  • com.liferay.portal.servlet.filters.*: There are loads of filters in liferay by default. They can be disabled if those are not getting used.

This list goes on like this but the best way to find or learn about the file is by going through it. One can search the property file using the following keywords to get more informations related to security: ‘secur’, ‘security’, ‘passowrd’, ‘encryption’, ‘auth’, ‘timeout’, ‘hash’, ‘encrypt’ etc.

This list goes on and on. As there is no end to securing your portal. Well security isn’t a state it’s a process. 

Nice blog Samujjwal Sir..It’s really very helpful article. We are waiting for some more helpful blogs from you emoticon

Hi Samujjwal, It’s really very helpful article for me.

Right now we are using liferay 7.2 DXP. Regarding Default Pages or Urls blocked by Front server,

I need to block the following URL's using Can you please suggest me how to do this ?

1. https://localhost:8080/o/frontend-css-web/main.css 

2. https://localhost:8080/favicon.ico