[wp-trac] [WordPress Trac] #62088: Prevent users that don't have unfiltered_html capability from adding code to custom post fields

WordPress Trac noreply at wordpress.org
Fri Sep 20 14:33:05 UTC 2024


#62088: Prevent users that don't have unfiltered_html capability from adding code
to custom post fields
--------------------------------+-----------------------------
 Reporter:  dartiss             |      Owner:  (none)
     Type:  enhancement         |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Editor              |    Version:
 Severity:  normal              |   Keywords:
  Focuses:  ui, administration  |
--------------------------------+-----------------------------
 The custom post fields meta box will allow anyone with access to the
 editor to add a custom field to a post. This includes adding code, such as
 Javascript. Of course, adding a field is useless without something to do
 something with it. Until now, it's been down to plugins that may store and
 do anything with the code in custom fields to be responsible for any
 filtering of the content. However, if I may quote our own guidelines
 ([https://developer.wordpress.org/apis/security/])...

 > Sanitation is okay, but validation/rejection is better.

 Would it not make more sense for core to prevent unfiltered HTML from
 being added to custom fields if the user doesn't have the appropriate
 permissions (right now, that's authors - editors and upwards have it)?
 That way it's not down to each use of these fields to find a way to
 achieve this - it's not always a case of always filtering the data, as
 unfiltered content may be required.

 I would suggest...

 1. Remove access to custom fields for those without the unfiltered_html
 capability. This is the easiest solution but most likely going to cause
 compatibility issues
 2. Make the custom fields read-only for those without the capability - it
 may still cause issues but at least people can view the content, and this
 can then come with a message explaining why it's restricted
 3. Allow those without the capability to make changes but then force the
 field to be filtered, ensuring that nothing can be done by those users
 that could be a concern

 I'm honestly not sure which is the best solution here but what is clear is
 that leaving these fields open to people without the appropriate
 permissions could be considered a security risk, if the appropriate
 plugins don't take action upon them.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62088>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list