Do not run kses on display filters for front page views

Description

Several display filters run wp_kses_data and other heavyweight functions. These functions are already run when saving. They were added to the display filters as a defense-in-depth for the possibility of an exploit sneaking things into the DB. Running these on the display causes a serious performance hit, however. wp_list_bookmarks() running kses on the link fields can burn up 10% of the total page load time. Let's limit running these functions to admin page displays. Displaying bad fields in the admin is more dangerous since those fields can cover their tracks. We can lose the belt and suspenders approach for front page displays where performance is more critical.

Isn't this contrary to security best practices? I mean, the database is obviously not supposed to contain insecure data. But it remains an untrusted source: if an SQL injection prone plugin allows anything malicious into it, this ticket ensures we're removing our last line of defense against XSS vulnerabilities and so forth.

Performance measured with xdebug and cachegrind. When Rasmus does his PHP performance presentation, we get dinged for how slow this is, particularly in wp_list_bookmarks() -> sanitize_bookmark_field() -> apply_filters() -> wp_kses_data(). Imagine if we did kses on post_content and post_title during display.

I did not know about that presentation by Rasmus. I watched it and I found it interesting that the only part where he found significant room for improvement was wp_list_bookmarks() (which many people don’t use anyway).