Purpose As mentioned by Daniel Beck in a comment some years ago creating a feature request is a way to introduce support for target attribute in link elements if Safe HTML plugin is used. I create a feature request of altering the policy OWASP Markup Formatter uses in order to allow target attribute in a elements somehow. Usage example My use case is adding links to parametr documentation on a wiki. Wiki, in my case is Confluence. I want those links to be there to allow 2 things:
- discoverability of parameter meaning for team newcomers,
- access to documentation by people with no access to Jenkins (I'm thinking POs and business people right now)
Security concerns Opening a new window/tab allows reading who opened it. It's summarised in https://developers.google.com/web/tools/lighthouse/audits/noopener To prevent security vulnerabilities I suggest only allowing target="_blank" (I assume the demand for other target values will be way lower than for _blank) and only if noopener is present in rel attribute unless it's a same-host link as recommended in the article above (think: a link to Jenkins itself). This however may not be immediately understandable by people who are not accustomed to web security (i.e. those who won't understand why noopener is important or will just not remember to use it. Think: most of the people, actually). Those people will still get frustrated on why doesn't target="_blank" work. I suggest the following:
- if target has other value than blank then remove it (as it works for all values now)
- if link is a same-host link: allow target="_blank" in case it's present.
- if it's not a same-host link, and there's no rel: add it. Set value to noopener.
- if it's not as same-host link, and rel is present but it has no noopener, add it so it's "/previousValue/ noopener" (rel is a DOMTokenList so it can have more than one value, values are space-separated. See https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement/relList)
|
