starpit commented on issue #4010: CORS headers work URL: https://github.com/apache/incubator-openwhisk/pull/4010#issuecomment-422398776 i believe that the trade-off we need to consider is Positive: this change allows for purely serverless clients Negative: i think there is only one exposed attack surface. if the client exposes the openwhisk AUTH as a javascript global variable, and the HTML origin CORS allows it to make outbound requests, then untrusted content can pick it up and begin invoking openwhisk (or any other endpoint) with that key. with the REST API CORS as it stands, at least this poorly designed client would be protected from third party calls (from the client) against openwhisk (though not from other third party endpoints). i think this is a pretty fine trade-off; to expound a bit: a well-designed client would keep the AUTH in either localStorage, sessionStorage, or cookies -- all three of which are protected by SAME-ORIGIN, independent of endpoint CORS settings. furthermore, it is worth noting that one can work around the REST API limitation by using a web action to proxy invoke and create requests (web actions offer better CORS support, though still with improper header limitations -- also fixed by this PR); however, this web action proxy will need to be multi-tenant; so, by forcing client developers to use a web action proxy, i claim that there is a large net negative in security.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
