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

Request: callback for failed CORS #313

Closed
pinko-fowle opened this issue Jan 5, 2024 · 5 comments
Closed

Request: callback for failed CORS #313

pinko-fowle opened this issue Jan 5, 2024 · 5 comments

Comments

@pinko-fowle
Copy link

pinko-fowle commented Jan 5, 2024

Hello. Currently cors can set headers, but it still let's the request go through the rest of the server middlewares.

The only present means to tell that something has gone poorly is to introspect on the headers, & find out that cors has set Access-Control-Allow-Origin: false. It would be pleasant to have a more obvious more formal way to check if cors is passing a request or not: a callback for cors failure would be a great addition.

@dougwilson
Copy link
Contributor

Yes, the request goes through bc that is what the cors spec calls for. Remember that CORS it not an authn system, and should not ever be used as such. CORS is simply a system to tell web browsers if the response body/headers can be read by certain javascript actions.

It is not clear by what you really mean by CORS failing though, as just bc the headers are not set doesn't mean much as it reallt depends on what the client decides to do, so only the client (web browser) can determine if there is an actual failure or not.

Can you provide some example of what you are trying to achieve, exactly?

@pinko-fowle
Copy link
Author

pinko-fowle commented Jan 5, 2024

Hi Doug. Honored by your extremely swift fast response. Thank you for the time (edit: and many years of hard work across Node.js ecosystem)!

We realize that CORS is not an authn system. But it still seems somewhat concerning that POST requests from external sites can hit us, and we'd like to lock this down a little more. We do have other CSRF mechanisms in place, but we'd feel safer doing some CORS validation server-side, & ending processing if it's not an expected origin.

I've found a tiny bit of discussion on the topic at the bottom of a stackoverflow... https://security.stackexchange.com/a/265002

@dougwilson
Copy link
Contributor

but we'd feel safer doing some CORS validation server-side, & ending processing if it's not an expected origin.

Ah.. unfortunately that was flagged as a vulun here bc that is authn behavior. It was removed so we don't have an active cve against the module. Unfortunately we cannot add this back bc according to the sec folks it will instill the idea that people can block requests with cors, which is unfortunately not true and there are a lot of holes in that and causes security issues bc folsk think it will work, especially when the module makes it seem thay way. The cors spec is to only add headers and not stop request processing. You can always add your own middleware right after the cors one to implement your own method to stop the request processing based on your own assessment. I hope thay helps.

@dougwilson
Copy link
Contributor

You can check the value using res.get('Access-Control-Allow-Origin') as part of your logic of course.

@pinko-fowle
Copy link
Author

pinko-fowle commented Jan 5, 2024

ACK. We've done so already. ;) Weird world. Forever indebted for much much much work of yours, & a very fast & great interaction on this. Thank you, closing.

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