Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add default santizer config#43271

Open
hamishwillee wants to merge 6 commits intomdn:mainfrom
hamishwillee:default_sanitizer_config_updates
Open

Add default santizer config#43271
hamishwillee wants to merge 6 commits intomdn:mainfrom
hamishwillee:default_sanitizer_config_updates

Conversation

@hamishwillee
Copy link
Collaborator

This add information on the Sanitizer default configuration and cross links it where needed.
@wbamberg @evilpie - would appreciate your review.

The information is specified in two places.

  1. An overview in the API overview page. This provides the gist and links to ...
  2. A separate guide page with a slightly expanded explanation, and a listing of the values.

I chose to do it in two docs , because the "full listing" is too much information for most users. I chose to put the "summary version" in the overview guide rather than in Sanitizer() because it is relevant to everything and worth knowing up front.

In addition, I made lots of minor spot changes that reflected a long-standing lack of understanding (mine) of the purpose of the default config vs the baseline remove config.

Essentially the default config removes more than just XSS-unsafe stuff - so this is more restrictive than what you get if you start with a custom config and call removeUnsafe on it.
The implication of the docs before this chang was that removeUnsafe would get you back to the default config.
The changes might still allow you to infer that in some cases, but I think I've been pretty clear that they are different now.

Related docs work can be tracked in #42755

Fixes #43226

@hamishwillee hamishwillee requested review from a team as code owners February 27, 2026 05:30
@hamishwillee hamishwillee requested review from dipikabh and removed request for a team February 27, 2026 05:30
@github-actions github-actions bot added Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed labels Feb 27, 2026
slug: Web/API/HTML_Sanitizer_API/Default_sanitizer_configuration
page-type: guide
---

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evilpie Note, this is your list, modified to:

  1. Make all the elements internal links.
  2. Elements listed first - generally I like to know about them first.
  3. Introduction explaining the rationall. Somewhat duplicated in the Concepts in the overview doc.
  4. Links to spec.
  5. NOte on the existence of the baseline spec for removal
  6. Global attributes somewhat grouped to make them easier to digest. This is arguable.

Copy link
Contributor

@mozfreddyb mozfreddyb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great update, thank you so much!

It's also great feedback for us as it indirectly points at some of our ommissions in the specification text.

My main concern was the mention of "and other unsafe elements" across the text, it's clear that we need to state more obivously why we disallowed extra things. I made a first attempt by giving examples as I am not sure how to best address that.

I also suggested some clarification on the composition of configurations, but was not entirely sure if my suggested locations are the best placement for these. Happy to see that improved regardless of where this is deemed most useful

- : A {{domxref("SanitizerConfig")}} defining a [valid configuration](/en-US/docs/Web/API/SanitizerConfig#valid_configuration), or the string `"default"` to indicate the default configuration.
- : A {{domxref("SanitizerConfig")}} defining a [valid configuration](/en-US/docs/Web/API/SanitizerConfig#valid_configuration), or the string `"default"` to indicate the [default Sanitizer configuration](/en-US/docs/Web/API/HTML_Sanitizer_API#default_sanitizer_configuration).

If omitted, the constructor returns a `Sanitizer` with the default configuration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also mention here that {} gives you an xss-safe sanitizer when using the safe function variants?

Maybe also mention that any kind of custom configuration (even when used with an unsafe function) can be made safe by calling removeUnsafe()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mozfreddyb I mentioned that {} can be passed because at this point it isn't clear whether it is a "valid config" - so worth saying.

However IMO constructor not appropriate level to discuss "how to make configurations safe".
That said, you wouldn't have mentioned it if this seemed well covered, so I have updated the Santizer to better cover this.

I also made consistent updates to update the text you identified about elements removed "for other reasons" with the examples provided (good call).

YOu can see those changes inhttps://github.com//pull/43271/changes/9a2da1b21d289e0a0da6dbe4fa891f86c2520a15

I think this addresses your issues.

@sideshowbarker sideshowbarker removed the request for review from a team March 3, 2026 05:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Including the HTML Sanitizer API's built-in safe default configuration

2 participants