diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/developer/client/swatches.md | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/docs/developer/client/swatches.md b/docs/developer/client/swatches.md index df4f643..ad11381 100644 --- a/docs/developer/client/swatches.md +++ b/docs/developer/client/swatches.md @@ -14,3 +14,13 @@ Things to consider: - For freeform values whose meaning is significant, provide buttons to let the user rapidly enter and experiment with interesting values. - Be thorough. Let the user experiment with values, even if you think those values may be nonsensical. - Try to show the component _without_ supporting markup, as far as is possible. However, if a component generates markup that requires context - a table row component needs a table, for example, or a list element needs a list - then include that markup in the swatch. + +## Swatches and XSS + +⚠ Swatches **should not** accept arbitrary HTML as user input and render it. Use something less expressive, instead. + +Swatches are an interface _intended for_ developers, but _available to_ everyone - including users who may not be familiar with the Web platform or the level of access a page might have to their credentials or data. Putting HTML inputs on a swatch invites the risk that a user may be mislead into running code in that swatch that then has access to the Pilcrow API, or to their locally-stored data. + +If a component takes HTML as an argument, then the best compromise we've found between allowing a swatch user to experiment with that HTML and protecting that user from these risks is to provide some kind of structured input. For example, a swatch for a message might instead allow test data to be entered using the same Markdown dialect real messages are entered with. + +For components where there isn't an easy way to do that, providing one or more predetermined test bodies is also a workable alternative. |