Missing sinks

[jonathanKingston]

We are missing some sinks here I think:

partial interface DOMParser {
    Document parseFromString(HTMLString str, SupportedType type);
};

partial interface HTMLIFrameElement {
     DOMString srcdoc;
};

Source: https://github.com/WICG/trusted-types/blob/master/README.md

I'm not sure how feasible it would be to check for the HTMLIFrameElement.

/cc @mozfreddyb

[mozfreddyb]

Ah, yes.

I think there are various issues we'll need to unpack (and given this will break codebases, the release following it will be another major version bump.)

• We could complain about .srcdoc = assignments and .setAttribute('srcdoc', …), that should be relatively easy.
• DOMParser.parseFromString is a bit funky, because the problem occurs later if and when somebody uses the document. Which is not a given for many uses of the API.

Since you already looked at Trusted Types, they go through a wider list of things beyond HTML fragments, i.e. assigning/replacing location, and href/src attributes for a specific set of elements. There are also some things we strictly can't do: Our static analysis has no knowledge of types and thus no way to distinguish <img src> from <script src>.

What are your further thoughts, @jonathanKingston?

[jonathanKingston]

DOMParser.parseFromString s a bit funky

Yeah I don't think it's an issue if parseFromString warns though, write is a popular function name for example too.

they go through a wider list of things beyond HTML fragments

We could add some "best guess" here like we do for write and writeln perhaps so anything that looks like script.

What are your further thoughts

That we really should address trusted types in the browser. I think our flexibility here is great and gives us some room to be stricter however we can only go so far as you mention.