simonw / datasette

An open source multi-tool for exploring and publishing data
https://datasette.io
Apache License 2.0
9.41k stars 671 forks source link

More flexible CORS support in core, to encourage good security practices #1143

Open yurivish opened 3 years ago

yurivish commented 3 years ago

It would be nice if the --cors option accepted an origin regex to more securely allow secure local development.

As an example, Observable notebooks namespace every user's notebooks by their username and user content is served from username.observableusercontent.com, so you would set --cors-origin username.observableusercontent.com to restrict access to a local development Datasette instance to only your own notebooks, rather than exposing the data to any website that makes a request.

Thank you for all of your work on Datasette!

simonw commented 3 years ago

Does this plugin do everything you need? https://github.com/simonw/datasette-cors

I'm open to arguments as to why this should be in core rather than in a plugin - I'm on the fence about that at the moment.

yurivish commented 3 years ago

From a quick look at the README, it does seem to do everything I need, thanks!

I think the argument for inclusion in core is to lower the chances of unwanted data access. A local server can be accessed by anybody who can make an HTTP request to your computer regardless of CORS rules, but the default * rule additionally opens up access to the local instance to any website you visit while it is running.

That's probably not what people typically intend, particularly when the data is of a sensitive nature. A default of requiring the user to specify the origin (allowing * but encouraging a narrower scope) would solve this problem entirely, I think.

simonw commented 3 years ago

That's a very convincing argument. I'm keen on making sure Datasette is "secure by default" so you're right, encouraging finely grains CORS rules in core rather than leaving that to a plugin sounds like the right call.

simonw commented 3 years ago

This may involve a breaking change to the CLI settings interface, so I'm adding this to the 1.0 milestone.

simonw commented 3 years ago

I think the right way to do this is to support multiple optional --cors-origin= pattern values, like you suggested.

simonw commented 2 years ago

The way Drupal does this is interesting; https://www.drupal.org/node/2715637 - it supports the following YAML:

  # Configure Cross-Site HTTP requests (CORS).
  # Read https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
  # for more information about the topic in general.
  # Note: By default the configuration is disabled.
 cors.config:
   enabled: false
   # Specify allowed headers, like 'x-allowed-header'.
   allowedHeaders: []
   # Specify allowed request methods, specify ['*'] to allow all possible ones.
   allowedMethods: []
   # Configure requests allowed from specific origins.
   allowedOrigins: ['*']
   # Sets the Access-Control-Expose-Headers header.
   exposedHeaders: false
   # Sets the Access-Control-Max-Age header.
   maxAge: false
   # Sets the Access-Control-Allow-Credentials header.
   supportsCredentials: false