Security best practices
Best practices for a secure Magnolia environment
Create a custom user with superuser role and deactivate the
superuseruser as soon as possible after installation.
Keep instances up to date.
Store public and author databases in separate physical locations. This minimizes the risk of data loss due to hardware failure or breach. The likelihood of a simultaneous event on both instances is less than that of a single instance in a different location. Failing suitable backup data, the surviving instance can be used to restore the instance on which the loss or corruption occurred. This tip is not Magnolia specific, just good common practice.
Delegate (move) the JCR repository and all folders referenced from the
magnolia.propertiesfiles outside the webapp.
Run your server with a user account that has only read access to the Magnolia webapp. This ensures that a potential attacker can’t use your write access to create a file with a malicious script for example.
Train users to create secure passwords. Thomas Baeddal’s article Usability of passwords covers the subject in depth.
Ensure that anonymous access to AdminCentral URLs is blocked on author and public instances. This is the default. Edit the
anonymousrole and create an ACL that denies access to
Alternatively, if or when you’re not using IP based filtering for access to AdminCentral on
public, be sure to restrict access to
If feasible, block access to the AdminCentral URIs for all users other than those inside the local network.
Servlet container and Web server configuration
Set up a SSL or TLS connector for Tomcat for encrypted communication and secure identification. Enable HTTPS for all sites managed in Magnolia. Instructions for Tomcat and Apache Web server.
Restrict access by IP address or remote host. Instructions for Tomcat and Apache Web server. IP filtering is available also in Magnolia at
/server/IPConfigwhere you can configure access based on HTTP method. Apply filtering to single IP addresses or to all IP addresses, indicated by using
*(asterisk). Regular expressions are not supported.
Attach a monitoring tool to your Tomcat instance for a better overview what is happening in the container. Try Lambda Probe or other JMX monitoring tools.
Serverresponse header field so it does not tell the version of Apache and operating system you are running. Attackers can use such information to their advantage. Apache Core: ServerTokens directive
Disable caching for secure content via no-cache headers. Do this in Magnolia browser cache policy.
Take cache-related measures that prevent Web Cache Poisoning attacks.
Enforce HTTPS for JSESSIONID cookies by setting
web.xml. Consider also enabling the
httpOnlysetting. Make sure you understand the impact of those settings on local development without a certificate.
Resolving a lockout
If you accidentally lock out
superuser and are unable to access AdminCentral:
If you still remember the
superuserpassword, use the Rescue App.
If you forgot the
superuserpassword, see Reset superuser account.
If you suspect the lockout is due to errors in recent configuration changes, see Rescue Security Support.
HTTP headers and security best practices
In this subsection, we provide some ideas how you can improve security through select HTTP headers.
Content Security Policy (CSP) header
You should list – as part of the header value – the origin and all the endpoints required for the page to function. However, if you allow any endpoint that is not within your control, you are opening a hole through which an attack might be staged. Therefore, be extra careful here.
If necessary, we recommend you customize the header to define your own whitelist.
Manually update the
Content-Security-Policyproperty value in the Configuration app.
An example final configuration could look similar to this:
Node name Value
default-src `self' `unsafe-inline' `unsafe-eval' https://ga-dev-tools.appspot.com https://apis.google.com https://www.google.com https://content.googleapis.com https://ajax.googleapis.com ; img-src `self' data:;
|The Vaadin framework performs the CSP check explicitly instead of relying on browser to do so as part of policy execution. You can see official Vaadin statement here.|
Strict-Transport-Security (STS) header
The STS header informs the browser that a page should only be accessed over the HTTPS protocol. The browser will use this knowledge and set all future requests for the same domain to go through HTTPS automatically, thus preventing the extra round trip that might be required otherwise.
Using HTTPS instead of HTTP enables traffic encryption between the page and the client, preventing anyone from intercepting the communication. Using this header is considered more secure than using the 301 redirect on the server when an attempt for the over-the-HTTP access is made.
X-Content-Type-Options (XCTO) header
XCTO is a marker header that tells the client that the media types (MIME types) advertized as part of the Content-Type headers should be strictly followed and not changed. This helps avoid MIME Type Sniffing.
X-Frame-Options (XFO) header
Setting the XFO header tells the browser that the given page is not allowed to be embedded in another page. This header setting helps mitigate stealing content, clickjacking (UI redress attack) or allowing malicious sites to pose as the regular ones and fool the users to not check the URLs closely but think instead that they are on a safe page when they are actually not.