-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
API returns 403 when Origin header is set without CORS setup #6204
Comments
AFAIK this is done on purpose to secure the API endpoint from arbitrary scripts in a browser. |
If the client side manage to do a non-CORS request when go-ipfs is setup for CORS, it will work no problem. This one make sense to me. My understanding is that CORS is a client side protection, so why not. If the client side try to do a CORS-enabled request when go-ipfs is not configured for CORS, it will be denied. This one doesn't make sense to me. By not configuring go-ipfs for CORS, we explicitly say that we don't care about CORS, but go-ipfs will still deny the request. I'm far from an expert on CORS, but I don't see how it protect anything. Could someone enlighten me ? Maybe it's a matter of having CORS configured by default ? |
If CORS is not configured then the default config is used which prohibits most CORS requests. |
Sorry, my point was that if go-ipfs has CORS properly configured by default (with |
The default is not |
This is a bit tricky. @MichaelMure is correct in that CORS is as a client-side standard that works through a send/read permissions table. Simple GET/POST requests are permitted, only reading the response inside the browser is denied (this is how any normal web server works -- the browser won't know to deny reading the request until it gets the response back without CORS headers, or else the corresponding preflight). From that POV, CORS configuration should have no impact on server response codes. On the other hand, we do want to secure the API! From that perspective, denying browser-originating requests from arbitrary Origins by default makes sense. The other option here would be to use an auth mechanism or token that the local client has access to, similar to how CSRF prevention works. I feel like this is an API design/documentation issue above all: in reality the |
another option might be to add something similar to Chrome's |
I think that even though we a have a slightly different POV, we pretty much agree. This is more a UX problem than a technical one. Yes, the API should be secure by default. My point is that there is situations where you want to drop that security, if only because it's handled somewhere else, but Now the question is how ? My view is that removing the CORS config should be enough. It's the less surprising solution which IMHO is a very important property in UX design. But as we are desling with security, an extra explicit |
In a similar fashing, there is #6213 |
@Kubuxu not sure if we talked about this yet but would be up for taking API security/access control on as a KR this quarter? |
So apparently, |
How I fixed thisI got stuck on this issue using docker.
It would be great if the CLI mentioned that config changes don't take effect until after a restart. Also, it's pretty odd that an improper CORS configuration would result in 403 errors and not, you know, CORS errors. |
Version information:
go-ipfs version: 0.4.19-
Repo version: 7
System version: amd64/linux
Golang version: go1.11.5
Type: bug
Description:
As shown in the previous example, if no CORS setup is done, any request with a
Origin
header will be denied. This breaks a few usecases, including handling CORS in a proxy sitting in front ofgo-ipfs
.The text was updated successfully, but these errors were encountered: