I had some people look over what I had built on Bubble and they said that it seemed to be vulnerable due to the Javascript and the potential for Cross-site Scripting. Now, I won’t pretend to truly understand what they were talking about, but doing a little research, it would appear that any user inputs have this vulnerability with Javascript. Is there a way to defend against this sort of hacking?
2 Likes
So here’s the tl;dr answer:
-If you use an HTML element, be very careful where that HTML comes from… if it comes from user-edited data, you have a potential cross-site scripting vulnerability. Generally, if you’re using the HTML element, you should be controlling the source of the HTML very carefully.
-However, other built-in Bubble elements should not vulnerable to cross-site scripting attacks. Ie, if you are just letting a user enter text with an Input, and displaying it with a Text, you should be safe. (If you’re aware of a specific vulnerability that we’ve missed, please send an email to security@bubble.is with details).
The longer answer…
Cross-site scripting attacks are when one user is able to upload some javascript and trick your website into displaying it to another user. That javascript can then do bad things like take actions on behalf of the user who is viewing it.
So, whether a website is vulnerable to that attack depends on how it displays user-entered data. If it takes user-entered data, and uses it as HTML, then anything you can do with HTML – including running javascript – can be done by any user.
So, in general, Bubble is very careful in how it displays user-entered data. All our user-facing elements display it as either plain text (ie, by setting the text property of an input, for instance), or, for situations where we want rich text, we use a safe subset of bbcode, which is a text-markup language that lets you change fonts and colors, but doesn’t let you write scripts or arbitrary html.
The one exception to that rule is the HTML element, which is a catch-all for power users to let them display whatever raw HTML they want. If you’re using an HTML element, you’re responsible for making sure the HTML is safe.
10 Likes
Thanks so much for your reply. So how I’m reading this is that as long as the user only has access to standard input elements then the risk for being hacked is mitigated?
Yep! Although it’s really about output, not input… if you use the HTML element to output user-entered data, that creates a risk, but if you use standard output elements like Texts, Buttons, Alerts, etc., you should be safe.
Good to know!
If we’re allowing users to enter text with a WYSIWYG input and then displaying it as HTML output, are there simple sanitizing tools/APIs we can use to ensure that we don’t run into cross-site scripting problems, etc.?
Trying to understand best practices. Strongly prefer to rely on a vendor who does this than attempt to code (and maintain) something that’s secure ourselves.