Blog

Pods 3.1 Feature Release: Access Rights Revamp

by
Pods 3.1 Feature Release: Access Rights Revamp

What’s new in Pods 3.1?

This is a Security focused release

While this release is meant to be as backwards compatible as possible, some aspects of security hardening may require manual intervention by site owners and their developers. Having trouble upgrading? Check out our Upgrade FAQ and Priority Upgrade Support form.

Important documentation for this release

Hotfixes are also available

Are you running an older version of Pods? A special release has been prepared for each major version back to Pods 2.7 but they do not include additional customization options and tools for Access Rights that are provided in Pods 3.1.

Note: The .1 versions of the hotfixes had a deployment problem on .org and were incremented to .2 to get around that issue.

Changelog

  • Security hardening: Introduced new access checks and additional fine-grained control over dynamic features across any place in Pods that allows embedding content or forms. This only applies to usage through Pods Blocks or Shortcodes. Using PHP will continue to expect you are handling this on your own unless you pass the appropriate arguments to the corresponding Pods methods. (@sc0ttkclark)
  • Security hardening: Prevent using the Pods Views Block / Shortcode to embed any files outside of the current theme. Props to the Nex Team / Wordfence for responsibly reporting this. (@sc0ttkclark)
  • Security hardening: Prevent output of user_pass, user_activation_key, and post_password through Pods dynamic features / PHP. These values will be set in Pods references to **************** if they were not-empty so you can still do conditional checks as normal. While Scott was already aware of this in pre-planned security release work, additional props go to the Nex Team / Wordfence for responsibly reporting this too. (@sc0ttkclark)
  • Security hardening: Prevent more unsavory PHP display callbacks from being used with magic tags in addition to those already prevented. Props to the Nex Team / Wordfence for responsibly reporting this. (@sc0ttkclark)
  • Feature: Access rights > Access-related Admin notices and Errors can be hidden by admins in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
  • Feature: Dynamic Features > Dynamic features (Pods Blocks and Shortcodes) can be disabled by admins in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
  • Changed: Dynamic Features > New installs will now default to not allowing all SQL arguments to be used by dynamic features. Existing installs will default to only allowing simple SQL arguments. All SQL fragments are checked for disallowed usage like subqueries. This can be set in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
  • Feature: Pods Display > The Display-related Pods Blocks and Shortcodes have additional checks that limit access to content based on the user viewing it. For Post Types that are non-public, they must have access to the read capability from that post type as a normal user. For displaying content from Users, they must have access to list_users capability to view that. Read more about how access rights work with Pods (@sc0ttkclark)
  • Feature: Pods Forms > The Pods Form Block and Form Shortcode have additional checks that limit access to creating/editing content based on the user submitting the form. For Post Types that are non-public, they must have access to the ‘create’ capability from that post type as a normal user. Forms that submit to the Users pod, now require that the submitter must have access to the create_users or edit_users capability to create or edit that user. Read more about how access rights work with Pods (@sc0ttkclark)
  • Feature: Pods Forms > The Pods Form Block and Form Shortcode now have a new option to identify the form with a custom key you choose that will get passed to various access-related filters so that developers can override access rights more easily. (@sc0ttkclark)
  • Feature: Pods Forms > When a user has access to create or edit content through a Pods form for a post type, the post_content field is cleaned based on the level of access they have to prevent inserting unintentional shortcodes or blocks. (@sc0ttkclark)
  • Feature: Markdown functionality has now been replaced by the Parsedown library for better security and performance and it’s uniquely prefixed so it prevents future conflicts with plugins using the same library. (@sc0ttkclark)
  • Changed: Pods Views > One of the breaking changes in this work is that the Pods Views Block / Shortcode dynamic feature is now disabled by default and must be enabled for new and existing installs. This can be done in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
  • Changed: Display PHP callbacks > New installs will now default to only allowing specific callbacks to be used. This defaults the specific callbacks allowed to esc_attr,esc_html which can be further customized in Pods Admin > Settings > Security. (@sc0ttkclark)

Background on this release

There were no known attempts to take advantage of the issues resolved by this release. Most of the issues have never even been reported to the Pods team aside from responsible disclosures to us by Wordfence through a security researcher where noted.

On a personal note — This is a release that I’ve been personally planning since WordCamp US in August 2023 when I realized that most people using Pods don’t recognize what WordPress does for Access Rights and Pods isn’t doing enough to elevate that. I’ve been developing this in depth, automated testing, and doing user testing. I’ve worked evenings, weekends, holidays, and in my otherwise free time to ensure that the end result is clean, secure, and reduces headaches for the existing sites that upgrade. I’ve probably spent somewhere around 100 hours of my time on this so that we didn’t have to pay extra development costs and our support could keep going from the already thin Friends of Pods budget.

The other issues and security problems I discovered along the way were addressed accordingly. I did my very best to address everything holistically and as clean as possible. I knew I had to backport everything to previous Pods releases which each had different minimum WordPress versions and minimum PHP versions supported. Nothing was easy and everything was time consuming to get right.

All that is to say — this was a lot of work! None of it would be possible without your support through Friends of Pods and Pods Pro by SKCDEV.

Extra special shout out for all of the moral support and help from these people who made life a little less solitary as I had to work on this in complete secret: