WebSocket Security

Deployment
,
1

Hi everyone,

I’m deploying a Streamlit dashboard on Azure App Service (with Azure Storage) and plan to expose it via a public URL for external users.

Internally, our cybersecurity team allows WebSockets only if they comply with the WebSocket Security Hardening Guide from WebSocket.org. Since Streamlit relies on WebSockets under the hood, I’m trying to understand whether Streamlit’s implementation aligns with these recommendations.

I don’t have a strong background in web development or cybersecurity, so I’m a bit stuck.

  • Does Streamlit’s WebSocket usage follow these security best practices?

  • If not, are there configuration options, logs or documentation I could use to reassure our security team?

Any guidance or experience would be greatly appreciated. Thanks!

2

Welcome to the Streamlit community and thanks for your thoughtful question! :blush: You’re right—Streamlit apps use WebSockets (via the Tornado web framework) for real-time, bidirectional communication between the browser and the Python backend. This is essential for interactive features and session management. However, Streamlit’s official docs don’t explicitly state compliance with the WebSocket.org Security Hardening Guide or provide a direct mapping to those recommendations.

It seems likely that Streamlit follows standard WebSocket security practices, such as supporting encrypted connections (wss://) and session isolation, especially when deployed behind HTTPS and a secure reverse proxy. You can enable HTTPS by configuring server.sslCertFile and server.sslKeyFile in .streamlit/config.toml, but for production, it’s recommended to terminate SSL at the load balancer or reverse proxy instead of the app itself. For additional security, Streamlit supports Cross-Origin Resource Sharing (CORS), Cross-Site Request Forgery (XSRF) protection, and session stickiness, all configurable in config.toml. For compliance evidence, you can share logs, configuration files, and reference the Streamlit architecture and security documentation and HTTPS support with your security team. If you need to demonstrate specific controls (e.g., origin restrictions, secure cookies, or XSRF), you may need to review and adjust your deployment’s proxy and server settings accordingly.

Sources: