The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
In #1834682: Consolidate filter options in the UI when configuring a format, we're trying to improve the UI for configuring a text format. One of the most confusing parts of configuring a filter is figuring out the "Filter order" options. To new users, these the filter order is baffling. Even experienced users sometimes need to grok code or parse through several modules' README.txt files to figure out the proper order for things.
Proposed resolution
Research and evaluate ways that we can make filter order more predictable for contributed modules to be "secure by default". Right now modules are able to provide a default weight for their filter, but that default is completely worthless once a user has rearranged the filters on a text format and then enables a new filter. After increasing the security of filters by default, consider reducing the prominence of the filter order, such as relegating it to a vertical tab, collapsed fieldset, or another approach.
Remaining tasks
Brainstorm, discuss, implement.
User interface changes
Reduce the prominence of filter order if we can ensure security by default.
API changes
TBD.
Comments
Comment #1
sunThis has been discussed in the past already, and I'm actually fairly sure that this issue duplicates an existing issue, next to a range of meta issues on text processors. Let's make sure that we're not duplicating prior art.
FWIW, I cumulated past conclusions and agreements on meta issues and started an implementation issue to revamp text formats and filters to a larger extent: #1828224: Split filter process into text processing and filtering
Comment #2
quicksketchMy first idea to improve the security of filtering is three-fold:
1) DO NOT ALLOW the "filter_html" filter to be disabled. It's always on and we remove the checkbox to disable it. However... you are able to configure the filter to allow all possible HTML tags, as well as a checkbox to disable the protection of event attributes, script src attributes, and style attributes. It's always been considered "best practice" to provide extensive tag lists rather than using the "Full HTML" format anyway. Forcing the filter to be on enforces this best practice and will encourage the user to add tags a-la-carte, rather than just disabling the filter_html filter.
2) Give the "filter_html" filter a CONSISTENT WEIGHT. For example, a weight of "0". The manual order of the filter_html filter is still exposed to the user, but its weight will always be 0. Filters above the filter_html filter are given negative weights, filters places below it are given positive ones. This allows contributed modules to have a predictable target for the main security filtering to be done, so they can position themselves properly by default, though the user can still override this ordering.
3) Make the "filter_html" filter (or potentially all filters) extensible and alterable. This will allow all security filters that should be run at the same time to have a predictable location. Modules such as WYSIWYG filter could amend or replace the "filter_html" behavior, rather than providing an entirely different filter. Within the multiple phases of the "filter_html" filter, modules could provide a code-only or hidden option to control their weight, as the number of filters that need to be run at this level should be minimal and be able to work together to find suitable weights (similar to the 'weight' in D7's system table or hook_hook_registry_alter()).
All of this is to say that the "filter_html" filter becomes the Grand Daddy of crucial security settings, allowing contrib modules to predictably compare themselves against a reliable target.
Comment #3
quicksketchCross-posted with you @sun. Any idea if I should repost to an existing issue or if this has been brought up before?
Comment #4
quicksketchThis *seems* like it's kind of related to #807996: [meta] Input filters and text formats, but that issue focuses primarily on DOM-based filtering which can be done in a separate post-processing layer. Even if that were implemented, the primary security filter would likely still need to be run somewhere as a part of the post-processing layer, so I think this issue of making the filter system more secure by default still stands. It's also much, much less ambitious than what's being discussed over there.
This issue does seem to overlap with #275811: Warn about potentially insecure filter configurations. Still reading through that one...
EDIT: Nope, still different. This issue focuses on making filtering more secure by default. The other issue is more about configuration warnings.
There is also #1782838: WYSIWYG in core: round one — filter types which was committed recently. I'm still trying to figure out the value-add of that issue. I don't think it will come into play as part of this issue since you'll likely want some security filters separate from the "filter_html" filter.
Comment #5
wim leersIt's indeed related to #807996: [meta] Input filters and text formats, specifically see #807996-19: [meta] Input filters and text formats. It tries to do more, but it takes into account a lot of aspects that strongly relate to having a general "security" phase.
#1782838: WYSIWYG in core: round one — filter types is indeed about not modifying the existing filter system, but about annotating it with sufficient metadata so that other modules can reason about text formats.
Overall, major +1 to the idea of having a general "security" phase. As long as Drupal is designed to serve a single format (HTML), this makes total sense. Users should always specify allowed HTML tags; but it should also be possible to define which attributes are (dis)allowed. If we always generate HTML, then it only makes sense to also always do that, right?
I still believe that the four-stage process in #807996-19: [meta] Input filters and text formats is sound overall.
Comment #6
sunSorry, neither Markdown nor BBCode have HTML tags? The filter system, as it currently stands, is designed to always output HTML, but the input is not necessarily HTML. Anyway, that seems to be completely off-topic for this issue.
#275811: Warn about potentially insecure filter configurations is spot-on related here, since it makes clear that a bogus filter order can leave your site in a completely insecure state.
The approaches being investigated there also clarify that determining a secure filter order is a hell of a complex job (which does not even involve to automatically correct or set it, which is another dimension of additional complexity). And, even if we had resolved that part, it would not be bullet-proof, so you couldn't even rely on it. From a security perspective, that's the most concerning part.
Therefore, our answer has always been:
The only remotely possible way I can see that would get us closer to a more guaranteed setup is the revamped architecture being outlined in #1828224: Split filter process into text processing and filtering — that is, because it would enforce a 1:1 relationship between a format and a text processor, whereas the text processor is responsible for security, and all other filters are separated out into the "dumping ground of filters doing whatever they want, but probably not security."
Comment #7
wim leersWhen you enter HTML directly, it is filtered on output
When you enter Markdown, it is converted into HTML, and still filtered on output.
Hence that is in fact a correct statement. Or am I missing something?
Agreed. That (#1828224: Split filter process into text processing and filtering) is essentially a combination of @quicksketch's #2 comment points 1 and 2, plus some more things. I don't think opinions/visions are that far apart, I just think @sun has thought more/further ahead about this (he's the filter system maintainer after all).
Comment #8
quicksketchRight, at the end of all output, it's always HTML. I don't think it would be unfair for us to say if you're producing non-HTML content, use a plain text area. Alternatively you could allow no tags at all, having them all be escaped and then html_entity_decode() before sending it to something else if you really wanted. Even if you were using BBCode or Markdown, there's a possibility you'd want to filter down tags anyway, such as to disallow h1-6 tags, imgs or others. With the current proposal, I would guess that BBCode/Markdown would still position themselves before the required security phases, but they could be places afterwards if you didn't want any manual HTML tags allowed. That's up to the user, but again BBCode/Markup filters (and others) would be able to secure by default. And that's what I'm trying to focus on here.
I've read through the other proposals for improving the filtering system, and perhaps I'm missing it, but while #1828224: Split filter process into text processing and filtering increases flexibility I don't see it inherently improving security unless you force the HTML tag/attribute cleanup.
Comment #9
wim leersMarked #618902: Design and implement a user interface for warning about insecure text formats as a duplicate.
Comment #23
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #24
smustgrave commentedSince it's been 3 months without a follow up going to close out, if still relevant for D11 please re-open!
Thanks!