fix(api): Add CORS support to API#3222
Conversation
The OSV API does not respond properly to CORS requests, for example a call to https://api.osv.dev/v1/query with Origin in the headers should return Access-Control-Allow-Origin: "*". According to https://cloud.google.com/endpoints/docs/openapi/specify-esp-v2-startup-options#cors , this change to the ESPV2 env variables should get the job done without requiring someone to go into the backend and mess with nginx / apache files.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Ok, no clue if I did this right or not, problem is that I won't really be able to tell until a build is pushed to either api.osv.dev or api.test.osv.dev . A couple of tests you can do:
|
dataprosconsulting
changed the title
|
Hi, could you update the PR description to include more details on what problem you're trying to solve here? What's the use case you can't perform today with the API configured as it is? |
|
Done. Let me know if I did it wrong or more clarity is needed. The short-and-sweet is that CORS checks are standard for web-based backends and web applications, so the API should be configured for CORS in order to enable those types of systems to leverage and integrate it. People using one of these backends can't call the OSV API without the change. Bypassing the checks is not recommended for security, it's easier to change one line in the ESV configuration to do the right thing than to tell every potential user of the API to do something that would raise their CISO's blood pressure. Sources for the rationale behind the change: https://stackoverflow.com/questions/41302753/does-a-restful-api-need-cors-implementation-anytime |
|
/gcbrun |
another-rex
left a comment
another-rex
left a comment
There was a problem hiding this comment.
Thanks for pointing this out! Let's see if this works.
|
/gcbrun |
|
Looks like the test site https://api.test.osv.dev is passing CORS responses correctly (meaning this change did what it was supposed to do!), but prod is not yet returning the CORS header:
Is there a separate CI/CD that has to run to promote that change to the prod endpoint, or a manual step necessary to restart that container? Since this change is an environment flag change, if you're using a "hotpatch" style test->prod promotion pathway it wouldn't take effect until a container refresh. Not an expert in the GC App hosting framework, but if it's anything like Kubernetes and has multiple HA/latency containers running, you have to round robin through the nodes to restart each instance, similar to how you would apply a major Kubernetes version upgrade. |
|
Seems to allow cross origin requests now on the test instance of the API, thanks! |
3 participants
The OSV API does not respond properly to CORS requests, for example a call to https://api.osv.dev/v1/query with Origin in the headers should return Access-Control-Allow-Origin: "*".
According to https://cloud.google.com/endpoints/docs/openapi/specify-esp-v2-startup-options#cors , this change to the ESPV2 env variables should get the job done without requiring someone to go into the backend and mess with nginx / apache files.
Why it's important: Integrations that use a webkit-based backend (or a Web Application Framework) when configured to security best practices will have CORS checks enabled for any non-same origin calls (meaning any curl/fetch calls made outside of the domain of the tool). While this can be bypassed by altering the Cross-Origin Resource Policy, it is not recommended to do so as CORS prevents certain kinds of XSS/remote hijacking attacks.
That means any integration system that does CORS checks cannot access the OSV API.
There is precedent for enabling this within the integrations OSV already is using - all of the CDN-pulled libraries and many of the data sources such as NIST are correctly sending CORS headers when resources are fetched from them. All NIST API endpoints have Access-Control-Allow-Origin: "*" in the header. It is a well-documented standard practice to enable this setting for public APIs, which OSV is.