Security best practices
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.
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.
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.
To configure the
securesession cookie attributes in Magnolia, add the following lines to the
web.xmlfile in your webapp’s WEB-INF folder./apache-tomcat/webapps/magnoliaAuthor/WEB-INF/web.xml
<session-config> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>
If you accidentally lock out
superuser and are unable to access AdminCentral:
In this subsection, we provide some ideas how you can improve security through select HTTP headers.
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.
Create a new filter manually in the Configuration app and add the
Content-Security-Policyproperty under it.
An example configuration could look similar to the one below. The path
server/filters/HeaderFilterOneis only a suggestion. When adding CSP headers, you only need to place the header values into the
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.|
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.
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.
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.