When to use enableCORS and enableXsrfProtection parameters?

🎈 Using Streamlit
1

Hi everyone,

In the Streamlit forum there are many examples of users adjusting enableCORS and enableXsrfProtection in their config.toml, but some of us don’t really understand these parameters :slight_smile:

  • When should we adjust the values of enableCORS and enableXsrfProtection vs. leave them at their default values?

  • Are there any identified common situations when developing and deploying Streamlit apps that require (or incline users towards) enabling/disabling these parameters?

4 Likes
2

Hi @marduk,

Really good question. I’d like to know the answer too to improve our documentation on config options. Give me until next week to get back to you? I’ll ping our Eng team internally for answers. :balloon:

1 Like
3

Hi @snehankekre ,

Let us know when you have news on this :slight_smile:

100% agree that documentation for config options in general can be improved :rocket:

2 Likes
4

Hey @marduk

So sorry for the delay :disappointed: Thanks again for resurfacing this thread. I’ve just posted your question to our internal support group. I’m waiting to hear back a response. Whenever I hear back, I’ll paste their response here verbatim.

1 Like
5

Hey @marduk, turns out we had to do some reading ourselves on enableCORS and enableXsrfProtection. Here are two responses I received. Let me know if you have any follow up questions.

Truthfully, CORS and Xsrf protection are very complex security policies that are difficult for most users. We enable them by default because they represent the most secure posture for Streamlit apps.

  • When should they adjust the values? Truthfully, they shouldn’t. They should only turn it off if they understand the security risk they are making by doing that. One can read up on CORS and Xsrf in MDN. There are plenty of videos, tutorials, and games that would instruct more on what this means.
  • Common situations: “My security consultant told me it’s okay.” “I am accepting the risk. There’s no sensitive information, etc”. Again, what Streamlit is doing is offering best practices. If they are hitting errors related to this, they should investigate the relevant issue and find the solution that satisfies CORS or XsrfProtection.

The topic is pretty complicated and I think we should anyway reference existing documentation (for example MDN!), and not try to explain security concepts ourselves. But, here are a couple insights I get from looking to our own codebase, related to the enableCORS and enableXsrfProtection Streamlit config options:

  • CORS is a shorthand for Cross Origin Resource Sharing, and our config option misleads users a little bit, because by setting enableCORS to True we actually disallow Cross Origin Resource sharing. It would be more correct and easy to comprehend if this option in our config would be called enableCORSProtection and we even have a corresponding TODO in our codebase streamlit/config.py at db7700d1843c3a0825d5b9c5d88e38d6d3cd3915 · streamlit/streamlit · GitHub In short, with omitting some details related to development mode, when enableCORS is False we allow requests for almost all our endpoints from any referrer, by setting self.set_header("Access-Control-Allow-Origin", "*") As I mentioned previously the enableCORSProtection is better name for it.

  • enableXsrfProtection is used for creating special token on backend and put that token in special cookie in our frontend, so when frontend will send request it should include that exact token, and we could be sure on backend that requests comes from our own frontend.

if config.get_option("server.enableXsrfProtection"): self.set_cookie("_xsrf", self.xsrf_token)

The interesting thing in our codebase is that we “respect” enableXsrfProtection more than enableCORS , which means when enableXsrfProtection is True, we always override enableCORS to True.From our logger warning message:

"""
Warning: the config option 'server.enableCORS=false' is not compatible with 'server.enableXsrfProtection=true'. 

As a result, 'server.enableCORS' is being overridden to 'true'. 

More information: In order to protect against CSRF attacks, we send a cookie with each request. 
To do so, we must specify allowable origins, which places a restriction on 
cross-origin resource sharing. 

If cross origin resource sharing is required, please disable server.enableXsrfProtection.
"""

Action items:

  • [Desirable] Research how difficult it would be to rename our config option to enableCorsProtection and is it possible without breaking backward comparability. I think single change will make this easier to comprehend, so if it possible we should do that! if I recall correctly, we had precedent of renaming config options in past?)
  • [Optional] Research (probably also consult with security specialist) on how CORS and XSRF things connected, and is it good thing to enable CORS protection automatically if XSRF protection enabled. (and should we do symmetric thing: enable XSRF automatically when CORS is enabled). I am not really understand the logic behind this sentence from quote of our warning above:

To do so, we must specify allowable origins, which places a restriction on cross-origin resource sharing.

But maybe I just miss something, and setting xsrf token places a restriction on cross-origin resource sharing.

4 Likes
6

Thanks a lot for sharing this @snehankekre, appreciate it :slight_smile:.

(Also the info about the potential naming improvement :rocket::rocket:.)

1 Like
7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.