With the update to v1.0.14 I noticed that with the stripIgnoreTag: true option set, strings containing < but no actual HTML began to be stripped at the point of the < character. Example, "x < 12" at v1.0.13 would be sanitized to "x < 12", but at v1.0.14 that same string would be sanitized to "x ".
Is this new behavior in v1.0.14 fixing prior incorrect behavior of stripIgnoreTag, or is it an unintended regression? Based on past behavior, it looks like a regression, but I would like to understand this as it does cause quite a big change when processing strings that do not contain actual HTML tags.
dasa
commented
2 months ago
Overview
With the update to v1.0.14 I noticed that with the
stripIgnoreTag: trueoption set, strings containing<but no actual HTML began to be stripped at the point of the<character. Example,"x < 12"at v1.0.13 would be sanitized to"x < 12", but at v1.0.14 that same string would be sanitized to"x ".Is this new behavior in v1.0.14 fixing prior incorrect behavior of
stripIgnoreTag, or is it an unintended regression? Based on past behavior, it looks like a regression, but I would like to understand this as it does cause quite a big change when processing strings that do not contain actual HTML tags.This behavior change seems to be caused by this commit: https://github.com/leizongmin/js-xss/commit/72844ddc6f59cb613312b92e58c090c5f414b6fb
Demo
I have created a CodePen where you can switch between v1.0.13 and v1.0.14 and see the change in behavior visually.