Security best practices

Best practices for a secure Magnolia environment

  • Create a custom user with superuser role and deactivate the superuser user 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.properties files 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 anonymous role and create an ACL that denies access to ./magnolia and .magnolia/*.

  • Alternatively, if or when you’re not using IP based filtering for access to AdminCentral on public, be sure to restrict access to ./resources and .resources/*.

  • 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/IPConfig where 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.

  • Change the Server response 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 secure to true in web.xml. Consider also enabling the httpOnly setting. Make sure you understand the impact of those settings on local development without a certificate.

    • Pre 6.2.23

    • 6.2.23+

    To configure the HttpOnly and secure session cookie attributes in Magnolia, add the following lines to the web.xml file 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>

    From Magnolia 6.2.23, you can also set the secure and httpOnly attributes on the CSRF cookie. Set these through AdminCentral at /server/filters/csrfTokenSecurity/csrfLogin.

    Property Description

    httpOnlyCookie

    optional, default is false

    A security setting that prevents cookies from being read by potentially malicious code.

    secureCookie

    optional, default is false

    Setting the property to true (recommended) will prevent cookies from being sent if the protocol used is insecure (HTTP instead of HTTPS).

Resolving a lockout

If you accidentally lock out superuser and are unable to access AdminCentral:

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

Content Security Policy governs what a web browser (or a user agent, in general) is allowed to load as part of a page. Setting a CSP header allows the creator of a page to control what other resources might be loaded by the underlying HTML or JavaScript code. This is a powerful way to mitigate many Cross-site scripting (XSS) attacks.

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-Policy property under it.

  • An example configuration could look similar to the one below. The path server/filters/HeaderFilterOne is only a suggestion. When adding CSP headers, you only need to place the header values into the Content-Security-Policy property.

    📁 server

         📁 filters

             📁 HeaderFilterOne

                 ⬩ class

    info.magnolia.cms.filters.AddHeadersFilter

                 ⬩ enabled

    true

                 📁 headers

                     ⬩ Content-Security-Policy

    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.

See also:

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.

See also:

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.

See also:

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.

See also:

Related topics
Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules