Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
yurivish opened this issue Dec 12, 2020 · 6 comments
Open

Comments

@yurivish
Copy link

yurivish commented Dec 12, 2020

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
Copy link
Owner

simonw commented Dec 14, 2020

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
Copy link
Author

yurivish commented Dec 14, 2020

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
Copy link
Owner

simonw commented Dec 14, 2020

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 simonw changed the title Allow more nuanced CORS rules More flexible CORS support in core, to encourage good security practices Dec 14, 2020
@simonw
Copy link
Owner

simonw commented Dec 14, 2020

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

@simonw simonw added this to the Datasette 1.0 milestone Dec 14, 2020
@simonw
Copy link
Owner

simonw commented Dec 16, 2020

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

@simonw
Copy link
Owner

simonw commented Feb 13, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants