[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