Security best practices

Best practices for a secure Magnolia environment

• 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.
• Change superuser password as soon as possible after installation. The default password is well known. Use the same password across all instances.
• 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/*.
• 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.

Resolving a lockout

If you accidentally lock out superuserand are unable to access AdminCentral:

• If you still remember the superuser password, see Re-enabling a locked out account.
• If you forgot superuser password, see Reset superuser account.
• If you suspect the lockout is due to errors in recent configuration changes, see Rescue Security Support.