Not all of the filters are complementary e.g. the NoSQL filter is designed to strip T-SQL keywords from content being passed to stored procedures, so is intended to be used by itself and not in combination with any other filter. Also, the NoAngleBrackets filter is not intended for most people, it was added per request of a major military entity that was having problems passing a security audit - for some reason their security team did not recognise the difference between htmlencoded content and unencoded content, despite our explanations and demos. Rather than risk getting DotNetNuke banned for no valid reason we added the NoAngleBrackets filter.

In general you use NoSQL for input used in dynamic sql or within stored procedures (via exec or sp_execute), you use NoScript if you want dangerous javascript and html tags used for xss/xsrf to be removed but "safe" html to be allowed, and NoMarkup to htmlencode all content. It's also likely that you'll combine NoMarkup and NoScript to ensure that only safe content stripped of javascript is stored.

Cathal

I've tested this a number of times and cannot replicate. What version of dnn are you using? The NoScripting filter has been in place since about 1.10, but it was tweaked a little while back. As with all filters it's designed for plaintext, but it was noticed that a lot of module developers were incorrectly passing htmlencoded content to it, so a while back (about 4.6 I think) I added additional code to try and detect if encoded content had been incorrectly passed,decode it, perform the checks and then return it to it's original encoded state. If you're using an old version of dnn, perhaps you are not passing the filter data correctly.

Cathal