A lot of us on the team consider the fact that we allow scripts to run by injecting them to be a bug that we can't remove for back-compat reasons, so we're sympathetic. I'll leave the ticket open for discussion to see if there's any way we can fix this.

What is preventing something like this:

// Beginning of IIFE or AMD or whatever...

var html = jQuery.fn.html;
var append = jQuery.fn.append;

jQuery.fn.html = function() {
   // do the filtering
   return html.call(this, filtered/safe stuff);
};

jQuery.fn.append = function() {
   // do the filtering
   return append.call(this, filtered/safe stuff);
};
  

// End of IIFE or AMD or whatever...

Nothing is preventing it, however, it is inefficient and risky. There are probably many paths to inserting HTML through jQuery, and without tracking them all down, the risk remains.

This is essentially what I'm doing right now, but I'm afraid I might have missed some corner case (and of course, methods change between versions, I don't want to have to keep updating this functionality). It would be much more efficient and safe to have one place to insert this functionality.

I just wrote up a blog post on everything we had to do to secure jQuery:

http://tech.blog.box.com/2013/08/securing-jquery-against-unintended-xss/

I would love there to be a formal HTML filter capability, and it seems like the injection points for that functionality are fairly straightforward (see the blog post).

I agree this would be nice to have.

Related: #14370; #14464

I don't know that we'd want to add ''another'' function for all input to pass through, but could definitely see exposing the arguments of our currently-existing .replace( rxhtmlTag, "<$1></$2>" ) as properties on jQuery. "Simple" extensions like no-innerHTML contents could still use a string replacement, but more complex ones like what this ticket is requesting could get wholesale filtering with something like the following (apologies for atrocious names):

var origPreMatch = jQuery.htmlPreMatch,
    origPreReplace = jQuery.htmlPreReplace;

jQuery.htmlPreMatch = /[\\w\\W]+/;
jQuery.htmlPreReplace = function( html ) {
    return extraProcess( html ).replace( origPreMatch, origPreReplace );
};

Replying to [comment:6 gibson042]:

Related: #14370; #14464 I don't know that we'd want to add ''another'' function for all input to pass through

If we passed it through $.escapeHTML only if it's a function then we're saved from one additional function invocation on each manip operation and the only overhead is one additional if. Is that a lot?

I feel regex might not be enough in some cases and we really should make it possible to secure our manip methods.

Replying to [comment:8 m_gol]:

If we passed it through $.escapeHTML only if it's a function then we're saved from one additional function invocation on each manip operation and the only overhead is one additional if. Is that a lot?

Well, it's still guaranteed to do at least two passes over the input (once for custom escaping and once to fix up self-closing tags) when someone sets up preprocessing, even if they're only trying to fix our mangling of script/textarea content (#14370) or attribute values (#14464). Come to think of it, that brings up the related question of whether preprocessing should precede, follow, or replace the currently-existing .replace( rxhtmlTag, "<$1></$2>" ).

I feel regex might not be enough in some cases and we really should make it possible to secure our manip methods.

str = str.replace( /[\\w\\W]+/, fn ) is equivalent to str = fn( str ) for any string-returning single-parameter fn, and therefore guaranteed to support the same use cases. This is purely a question of API surface area.

Migrated to https://github.com/jquery/jquery/issues/1747