v6.1.0

Features

• Added the text-decoration-skip-ink and text-decoration-thickness CSS properties to the relaxed config. @martineriksson - #228

v6.0.2

Bug Fixes

• CVE-2023-36823: Fixed an HTML+CSS sanitization bypass that could allow XSS (cross-site scripting). This issue affects Sanitize versions 3.0.0 through 6.0.1.

  When using Sanitize's relaxed config or a custom config that allows <style> elements and one or more CSS at-rules, carefully crafted input could be used to sneak arbitrary HTML through Sanitize.

  See the following security advisory for additional details: GHSA-f5ww-cq3m-q3g7

  Thanks to @cure53 for finding this issue.

v6.0.1

Bug Fixes

• Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

  This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

  Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

  The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

  See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

  Thanks to David Klein from TU Braunschweig (@leeN) for reporting this issue.

• Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was allowlisted and was also inside an allowlisted <math> or <svg> element.

  The only way to encounter this situation was to ignore multiple warnings in the readme and create a custom config that allowlisted all the elements involved, including <math> or <svg>. If you're using a default config or if you heeded the warnings about MathML and SVG not being supported, you're not affected by this issue.

  Please let this be a reminder that Sanitize cannot safely sanitize MathML or SVG content and does not support this use case. The default configs don't allow MathML or SVG elements, and allowlisting MathML or SVG elements in a custom config may create a security vulnerability in your application.

  Documentation has been updated to add more warnings and to make the existing warnings about this more prominent.

  Thanks to David Klein from TU Braunschweig (@leeN) for reporting this issue.

v6.0.0

Potentially Breaking Changes

• Ruby 2.5.0 is now the oldest officially supported Ruby version.

• Sanitize now requires Nokogiri 1.12.0 or higher, which includes Nokogumbo. The separate dependency on Nokogumbo has been removed. @lis2 - #211

v5.2.3

Bug Fixes

• Ensure protocol sanitization is applied to data attributes. @ccutrer - #207

v5.2.2

Bug Fixes

• Fixed a deprecation warning in Ruby 2.7+ when using keyword arguments in a custom transformer. @mscrivo - #206

v5.2.1

Bug Fixes

• Fixed an HTML sanitization bypass that could allow XSS. This issue affects Sanitize versions 3.0.0 through 5.2.0.

  When HTML was sanitized using the "relaxed" config or a custom config that allows certain elements, some content in a <math> or <svg> element may not have beeen sanitized correctly even if math and svg were not in the allowlist. This could allow carefully crafted input to sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

  You are likely to be vulnerable to this issue if you use Sanitize's relaxed config or a custom config that allows one or more of the following HTML elements:

  • iframe
  • math
  • noembed
  • noframes
  • noscript
  • plaintext
  • script
  • style
  • svg
  • xmp

  See the security advisory for more details, including a workaround if you're not able to upgrade: GHSA-p4x4-rw2p-8j8m

  Many thanks to Michał Bentkowski of Securitum for reporting this issue and helping to verify the fix.

v5.2.0

Changes

• The term "whitelist" has been replaced with "allowlist" throughout Sanitize's source and documentation.

  While the etymology of "whitelist" may not be explicitly racist in origin or intent, there are inherent racial connotations in the implication that white is good and black (as in "blacklist") is not.

  This is a change I should have made long ago, and I apologize for not making it sooner.

• In transformer input, the :is_whitelisted and :node_whitelist keys are now deprecated. New :is_allowlisted and :node_allowlist keys have been added. The old keys will continue to work in order to avoid breaking existing code, but they are no longer documented and may be removed in a future semver major release.

v5.1.0

Features

• Added a :parser_options config hash, which makes it possible to pass custom parsing options to Nokogumbo. @austin-wang - #194

Bug Fixes

• Non-characters and non-whitespace control characters are now stripped from HTML input before parsing to comply with the HTML Standard's preprocessing guidelines. Prior to this Sanitize had adhered to older W3C guidelines that have since been withdrawn. #179

v5.0.0

For most users, upgrading from 4.x shouldn't require any changes. However, the minimum required Ruby version has changed, and Sanitize 5.x's HTML output may differ in some small ways from 4.x's output. If this matters to you, please review the changes below carefully.

Potentially Breaking Changes

• Ruby 2.3.0 is now the oldest officially supported Ruby version. Sanitize may work in older 2.x Rubies, but they aren't actively tested. Sanitize definitely no longer works in Ruby 1.9.x.

• Upgraded to Nokogumbo 2.x, which fixes various bugs and adds standard-compliant HTML serialization. @stevecheckoway - #189

• Children of the following elements are now removed by default when these elements are removed, rather than being preserved and escaped:

  • iframe
  • noembed
  • noframes
  • noscript
  • script
  • style

• Children of whitelisted iframe elements are now always removed. In modern HTML, iframe elements should never have children. In HTML 4 and earlier iframe elements were allowed to contain fallback content for legacy browsers, but it's been almost two decades since that was useful.

• Fixed a bug that caused :remove_contents to behave as if it were set to true when it was actually an Array.