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 third party scripts 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. [ Full content available at: https://github.com/apache/incubator-openwhisk/pull/4010 ] This message was relayed via gitbox.apache.org for [email protected]
