Jump to main content Jump to doc navigation

The MODX 2.8.2 release contains several security improvements, which may have an adverse effect on existing sites. This document details the potential impact and how to address them.

Static resource paths

After upgrading to 2.8.2 all static resources are restricted to the assets directory by default unless you've previously configured resource_static_path. Static resources located anywhere else (core, outside the webroot, etc) will throw a 404 (#15656).

If you use static resources and store them anywhere else, you have a few options:

  1. (Recommended) Adjust the resource_static_path system setting to provide the absolute path in which your static resource files are located. For example if you store your static resource files in core/files/, adjust the setting to {core_path}files/. If your static resources are anywhere in the root of the website, you can use {base_path}.
  2. (Not recommended) Enable the new resource_static_allow_absolute system setting, which will allow any valid absolute path to be provided to the static resource.

Important: enabling resource_static_allow_absolute, or configuring a too wide path in resource_static_path will allow a malicious manager user to access any file on the file system, including files that may not be meant to be disclosed, such as configuration files or server files. Either set it to a publicly accessible directory like assets, or a directory specific to static resources, so that no files can be read that a user should not have access to.

Previously the new_static_resource, new_weblink and new_symlink permissions existed and affected what resource types showed up in the resource tree toolbar, however they were not actually enforced and easily bypassed by either editing an existing resource to change its type, or setting the resource type to use in the URL parameters.

In 2.8.2 the permission to create those resource types are enforced, and new permissions were added to offer more control over editing and deleting those resource types, as well as enforcing the permissions to create them.

The core-provided "Administrator", "Content Editor" and "Developer" access policies have been updated to include these permissions by default. If you have custom policies and expect your users to be able of managing static resources, weblinks or symlinks, you'll need to add the following permissions: edit_weblink, edit_symlink, edit_static_resource, delete_weblink, delete_symlink, delete_static_resource. The generic edit_document and delete_document permissions are also required.

Custom Manager Themes

If you use a custom manager theme, you may find the manager no longer works after the upgrade. A variety of error messages may appear in the developer console, which are the result from heightened security on loading the configuration (#15644).

Find the custom theme's header.tpl file (e.g. manager/templates/mytheme/header.tpl) and replace the modx.config.js.php script reference from:

<script src="{$_config.connectors_url}modx.config.js.php?action={$smarty.get.a|default|htmlspecialchars}{if $_ctx}&wctx={$_ctx}{/if}"></script>

to the following which includes providing the HTTP_MODAUTH token:

<script src="{$_config.connectors_url}modx.config.js.php?action={$smarty.get.a|default|htmlspecialchars}{if $_ctx}&wctx={$_ctx}{/if}&HTTP_MODAUTH={$_authToken|default|htmlspecialchars}"></script>