Why is using HTML unsafe?

Hi,

Could someone please briefly explain why using HTML is unsafe?

A clear answer would help me understand safe boundaries whilst working with streamlit.

Apologies for my naivety on this subject. Streamlit is great, my programming skills are not:-)

Danny

Hi @dahanoo, welcome to the Streamlit community!

This is a great question…we refer to HTML as “unsafe” as a keyword argument, to highlight the fact that you can run JavaScript within the widget.

We’re highlighting the fact that Streamlit itself will not be able to prove the code’s safety, since a malicious 3rd-party could inject code into your website, or the Streamlit app creator might write code in such a way as to allow for code injection attacks. So by default, we disable evaluating code inside of an HTML snippet, but allow a user to set the keyword argument to say “I understand that this is potentially risky, but I want to do it anyway”

3 Likes

Hi Randy,

Excellent, thanks for the clear answer and the article. Fully understood now:-)

I guess for a lot of people the HTML unsafe issue is manageable. The need to understand and monitor potential issues is a must though.

Danny

As you said, I see that <script> tags are removed with st.markdown(raw_html, unsafe_allow_html=True).

If that’s case, (that is, if we cannot inject JS using that), why is this still called unsafe?

Thanks for pointing this out, my answer is imprecise in referring to JavaScript. That’s a separate type of attack than HTML. Here’s a longer explanation:

http://kb.enprobe.io/vulnerabilities/html-injection.html

So the point of naming the parameter that way is to highlight that if you are injecting custom HTML into your app, it’s up to you to make sure you’re defending against this type of attack.

1 Like

I get it now, thanks!