Blog

Pods Constants and Security

by

In order to prevent the possibility of untrusted user passing potentially malicious data into the WordPress database, recent versions of Pods introduced several constants, which by default disable potentially dangerous usage. Some of these usages are common usage. When they are only available to trusted users they may be perfectly fine to use. This post details several common usages that must be explicitly enabled via a constant. In addition, it details the potential risks of enabling this behavior.

Please note that there is a complete list of Pods constants available here. In addition keep in mind that while Pods 3.0 will include a settings screen to enable or disable much of the functionality discussed in this post. These settings will not have effect if the constant is already defined.

In most cases these constants should be defined in your site’s wp-config file. If you are not familiar with editing PHP constants, in the wp-config file in WordPress, see this codex article.

Pods Shortcodes

When processing the Pods Shortcode, there are several constants that must be enabled to get full functionality that are disabled by default for security reasons. For example, the constant PODS_DISABLE_SHORTCODE_SQL, when defined as false, allows the use of the “orderby”, “where”, “having”, “groupby” and “select” arguments. By defining this true, or not defining it, you prevent the shortcode from passing SQL that could potentially be used to used to compromise site security.

There are two others constants that affect shortcodes–PODS_SHORTCODE_ALLOW_EVALUATE_TAGS, and PODS_DISABLE_SHORTCODE. The first one, PODS_SHORTCODE_ALLOW_EVALUATE_TAGS, when it is defined as true, allows shortcodes to evaluate tags like magic tags, but through pods_v(). The other PODS_DISABLE_SHORTCODE disables the Pods Shortcode entirely.

We encourage users to only define PODS_DISABLE_SHORTCODE_SQL as false when only trusted users are able to edit posts on their site. If you need the functionality offered by “orderby”, “where”, “having”, “groupby” and “select” arguments, you are encouraged to use the Pods class directly to accomplish what the shortcode does.

Evaluate PHP In Pods Templates or Pods Pages Page Code and Precode

Using PHP in Pods Templates is deprecated, but will work unless you define PODS_DISABLE_EVAL as true. Using PHP in Pods Templates remains possible as there are several valid use cases for doing so. The plugin Pods Frontier, removes the limitations that previously lead to the use of PHP being required in the Templates editor. While Pods Frontier is still in beta at this time, its enhancements to Pods Templates are totally functional.

Allowing Templates to evaluate tags via the PODS_DISABLE_EVAL is only recommended when not using Pods Frontier. We strongly recommend that if you use Pods Templates, that you use Pods Frontier as it significantly enhances their capabilities.

This constant also affects Pods Pages precode and page code, which we recommend you do not use. The usage of both is deprecated. It is better to use the WordPress page template that outputs the Pods Page for all of the PHP you need. Alternatively you may use the ‘pods_content’ filter.

Other Security Related Constants

  • PODS_DISABLE_FILE_UPLOAD – If defined as true prevents uploading media from Pods fields.
  • PODS_UPLOAD_REQUIRE_LOGIN – If defined as false, non-logged in users can upload files. Set to false with caution, can present security risks.
  • PODS_DISABLE_FILE_BROWSER – If defined as true, disables access to the file browser when uploading files via Pods file fields.
  • PODS_FILES_REQUIRE_LOGIN – If defined as false, users who are NOT logged in may upload files via Pods file fields. Use this with caution.

Questions or Concerns? Let Us Know?

If you have any questions about implementing any of this on your site, please post in our support forums. If you believe you have found a security issue with Pods, for the security of all users, we ask that you not publicly disclose the issue until we have had time to address it. If you believe you have found a security vulnerability in Pods we ask that you contact our team directly at [email protected]. You may also choose to contact [email protected] in addition with any security concerns about Pods or any other plugins hosted in the WordPress.org repository.