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.

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>

Configure a restrictive Content Security Policy (CSP) for production deployments.

A restrictive CSP helps protect against Cross-Site Scripting (XSS) and clickjacking attacks by controlling what resources can be loaded on your pages. For more details, see HTTP headers and security best practices.

Importing content

To mitigate the risk of security vulnerabilities when importing content, restrict the use of import commands to trusted users. Limiting who can import files offers another layer of protection to your environment. See Restricting actions for more information.

Resolving a lockout

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

If you still remember the superuser password, use the Rescue App.
If you forgot the superuser password, 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

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) and clickjacking attacks.

CSP configuration is mandatory for production deployments. You should configure a restrictive CSP on all HTML resources before deploying to production.

CSP Level 2 is supported by all major browsers and should be used for production deployments.

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.

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.

Strong CSP level 2 policy example

For production deployments, use a restrictive CSP Level 2 policy such as the example one below.

Content-Security-Policy: default-src 'none'; script-src 'nonce-r4nd0mN0nce'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; report-uri https://cspreport.example.com/log

This policy:

default-src 'none' - Blocks all resources by default
script-src 'nonce-r4nd0mN0nce' - Only allows scripts with the specified nonce
frame-ancestors 'none' - Prevents the page from being embedded in frames (clickjacking protection)
base-uri 'self' - Restricts base element URLs to same origin
form-action 'self' - Restricts form submissions to same origin
report-uri - Sends violation reports to the specified endpoint

Development configuration

During development, you can enable reporting of violations without blocking content by using the Content-Security-Policy-Report-Only header instead of Content-Security-Policy. This allows you to test and refine your policy before enforcing it in production.

JSON requests are processed when Content-Type is text/plain?

This does not present a security vulnerability in Vaadin. Vaadin doesn’t enforce Content-Type: application/json because it doesn’t rely on it for security.

Requests with an incorrect Content-Type fail if the content is malformed. This ensures compatibility with technologies like Portlets. For more details, see Advanced Vaadin Topics: Content Type Incorrectly Stated.

Vaadin secures requests using CSRF tokens, not Content-Type validation.

CSP evaluation and testing

Use the CSP Evaluator tool to test and validate your Content Security Policy configuration. This tool helps identify potential security issues and provides recommendations for improving your policy.

`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.