Hi @dsw88! Welcome to the forums
I’d love to get some more detail on the kinds of assurances you’re looking for (see my responses below).
As a preface, though, I think it’s important to realize that since Streamlit is a framework for easily building data apps in Python, by its very nature it comes with the full power of Python. We work hard to design our APIs to make it trivial for developers to Do The Right Thing™ by default, but since you can use any Python you want it’s possible for developers to do Wrong Things as well.
For example, there’s nothing in Streamlit that will stop a developer from doing something like this:
code = st.text_area("Python code")
exec(code) # <-- Bad idea!
So an important distinction here is the exact kind of vulnerabilities are you worried about: those that originate from Streamlit’s own codebase? Or from apps written by Streamlit users?
- Is any user-entered data logged automatically by Streamlit? If so, is the data sanitized to avoid inject XSS into the log files?
No, Streamlit doesn’t log anything automatically.
- Are all input fields validated to check for format and length on the server side?
- Were standard libraries also used to validate input fields on the server side?
- i.e. you didn’t write input validation using custom code, but used a well-vetted community library
What kinds of checks and validations are you interested in? And what classes of vulnerabilities?
If I understand your question correctly, checks of this sort are very much application-dependent. So it makes sense to leave it up to the user to implement them.
In addition to the above specific questions, can you provide some detail on what you do in Streamlit to protect against common application vulnerabilities, such as those relevant ones on the OWASP Top 10 list?
When I worked at Google, if we wanted to use certain external libraries in production we had submit them through a security review. This is something I would love for companies to do with Streamlit! Let me know if you’re interested. We’d be happy to meet any time and help guide you through our codebase to move this process forward. The more eyes we have on the code, the better
In the meantime, I’m happy to give to the following outline of an answer:
Injection - As demonstrated above, this is the Streamlit app developer’s responsibility.
Broken Authentication - Streamlit doesn’t have built-in authentication.
Sensitive data exposure - Similarly, this is the Streamlit app developer’s responsibility.
XML External Entities (XXE) - Streamlit doesn’t use XML.
Broken Access control - Streamlit doesn’t have built-in access control.
Security misconfigurations - Streamlit isn’t a cloud service so we don’t have security configurations.
Insecure Deserialization - This is the Streamlit app developer’s responsibility.
Using Components with known vulnerabilities - Streamlit does not deserialize objects from untrusted sources.
Insufficient logging and monitoring - Similar to above, this is the Streamlit app developer’s responsibility.