Allowing customization of the position of the style, why does the style content also need to be filtered?
Why even the style content needs to go through a filter? Because the style is not just a presentation layer description text: the attribute names and values can point to external resources, can change the presentation of page elements, and can also replace the visible content with another set. In this round of security fixes, the WordPress official listed the issue of CSS injection achieved by users with Author and above roles bypassing the security style attribute filter, the direction of treatment is to do whitelist filtering on the style content itself, rather than just checking if it can be parsed.
What can be hidden in the style?
Common types. One type is to reference attribute values from external addresses, where the page sends requests to services outside the site; another type is to cover layout values, which can obscure or replace existing content, affecting what visitors see in the text; and another type is the writing style that联动 with script behavior, affecting page interaction by changing the visibility of elements. All three types do not require script tags, yet they can all change the actual experience of visitors, which is why 'Filtering tags alone is not enough to prevent style injection.'
Why is the whitelist filter bypassed
Filter three segments at the same time: selector, attribute name, and attribute value. Only the attribute name is released without limiting the value, and external addresses can be included in the value; only check the literal value of the attribute, encoding transformation and splicing writing may bypass it; only look at the text submitted at the time, and it can be spliced together with other segments after being stored in the database to form the unopened writing.
Therefore, the scope is 'dual whitelist plus review before storage': a list of allowed attribute names and allowed value forms are listed separately, and a final check is made on the merged final text before writing. This is the same approach as the rich text content filtering, but the object has changed from tag to style.
The three segments of content to be filtered over.
The first is the structure and semantics layer. The in-station sensitive word filtering and keyword replacement processing of text content, content review for the pre-publication review, style filtering should be listed together, and cannot be considered as having been solved by the rich text filter. The second is the identity and authentication layer. The JWT authentication at the back-end entry is responsible for determining who the request comes from, and this is two issues with「whether the style submitted by this person is safe」. The third is the out-station processing of anti-crawling and interference codes, which change the rendering of the text but do not change the judgment object of the style filtering.
There is still protection against script injection and database injection within the site, style filtering is a link in the same content security boundary, and if it is missing, no matter how strict the other layers are, gaps will appear from this entry.
Who can write custom styles
The exposed surface is determined by the role. The wider the range of roles that can be written with a custom style, the stricter the filtering rules should be; if only the site administrator can change it, it is still recommended to keep the filter to prevent it from being reused in batch imports or template content. AnQiCMS provides visual template editing capabilities, and the modification of templates and styles is a routine operation in authorized roles. Changes to such locations should also follow the same filtering and review criteria, rather than skipping them because 'it is written by the administrator.'
This issue in the official repair list is for Authors and above roles, it indicates that 'Trusted Role' is not an exemption condition; the release notes also remind that only newer versions are actively supported, and leaving such repairs outside the old versions will continue to expose them.
Can't we just turn off the custom style entry?Yes, this is the most convenient way to handle it. If the business really needs it, it can be opened in two steps of dual whitelist and final text review.
Will filtering styles written by administrators also cause harm?Answer: There will be a normal release method that needs to be opened, which is to add the confirmed safe attributes and values to the whitelist instead of skipping the filtering for the entire role.
Question: Should the styles in the template file be checked in the same way?Answer: The template belongs to the code layer and is generally controlled by the deployment process; only the style fragments that can be submitted in the external form need to be filtered at runtime, and the control means are different but the judgment criteria should be consistent.