Adoption of CORS as per FAPI standard

[CDR-API-Stream]

Description

The FAPI read profile, in section 6.2.1 encourages the use of CORS for resource end points that are anticipated to be made available for javascript clients

Area Affected

The security profile, specifically unauthenticated resource APIs but potentially also the authenticated resource APIs

Change Proposed

Adopt the requirement that holders allow CORS (ie. Access-Control-Allow-Origin: *) for resource end points.

[perlboy]

Quoting from FAPI-R profile:

The resource server with the FAPI endpoints should support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable JavaScript clients to access the endpoint if it decides to provide access to JavaScript clients. NOTE: Providing access to JavaScript clients has other security implications. Before supporting those clients [RFC6819] should be consulted.

"Javascript clients" referenced here is actually end user browsers. CORS is not required for server side js (ie. nodejs) and the FAPI-R profile does not require CORS headers to be present.

The change proposed forces all participants to send a false assertion it wants browser based clients from any location *" ( ) "** and is not aligned with FAPI-R as it converts a recommendation into a mandatory requirement.

Not requiring CORS is for good reason based on UK experience, if someone was to create an app and serve Barclay's branches they'd be loading this payload into their browser: https://atlas.api.barclays/open-banking/v2.1/branches <---- Does not have a CORS header, 1.72MB payload.

[CDR-API-Stream]

This is reasonable feedback. There is no scenario allowed for the CDR regime whereby a public client can access a resource end point requiring authentication.

The case of unauthenticated end points is (i.e. status, planned outages and PRD) remains, however. These end points were intended to be accessible by public clients so the inclusion of allow-all CORS headers in this scenario would be beneficial for some client implementation scenarios.

The proposed changed could be reasonably constrained to apply only to unauthenticated resource end points.

[perlboy]

This is reasonable feedback. There is no scenario allowed for the CDR regime whereby a public client can access a resource end point requiring authentication.

..... "Thanks" I guess. I'm not going to refer to previous comments on this but the public client should have the option of authenticating the endpoint (this is a two-way trust not a one-way one) and since Product Data is ONLY available (versus dual published to public access intended vs. CDR participants) via this endpoint this option is delegated outside the Australian governments authority.

This represents a split use case that could be easily solved by having an "unauthenticated" endpoint that includes CDS specific endpoints but CDR enforced trust chains. This could include product data in addition to public endpoints.

The case of unauthenticated end points is (i.e. status, planned outages and PRD) remains, however. These end points were intended to be accessible by public clients so the inclusion of allow-all CORS headers in this scenario would be beneficial for some client implementation scenarios.

Yes it would be but doing so for both use cases impacts the trust chains for a majority client implementation scenarios (browser serve vs. aggregation). I question whether this trade off is justified.

The proposed changed could be reasonably constrained to apply only to unauthenticated resource end points.

Unauthenticated != Public. There is a merging of domains occurring here between product data and status/outages.

As this is standards-maintenance is there a specific demand for this from participants? If so, where?

[CDR-API-Stream]

This issue was raised by the independent security review, by the DSB engineering team and via various workshops and interactions with potential users of the PRD data such as comparison websites.

The accommodation of a public client paradigm for accessing the PRD data has always been intended (ie. accessing these APIs without the need for a server side implementation).

[CDR-API-Stream]

Based on the above, and other consultation, the current recommendation for this change proposal is that the standards will require CORS for unauthenticated end points (including PRD, status and planned outages) but that this will not be required (above existing requirements included in normative references) for authenticated end points or security end points.

[perlboy]

This issue was raised by the independent security review

For clarity the Independent Security Review stated the following on Page 29 and as outlined in my response 25 July:

This:

1) Mentioned the UK profile but did not mention this was an optional requirement 2) States CORS "may need to be specified in future if browser-side access is required, at which point cross-domain security attacks can emerge"

Further the absence of public client access was classified as a positive security criteria outcome (Page 27):

When I asked for clarification about was considered in-scope on the report the reply was:

All aspects of the CDR standards published in the May draft were considered in scope for the review. This included the Product APIs.

At a bare minimum the security assessment given with respect to the adoption of CORS has not been fully assessed.

by the DSB engineering team and

Yes, as a result of the proof of concept production of the client only Product Comparator application. A comparison application value proposition funded by the Australian government.

via various workshops and interactions with potential users of the PRD data such as comparison websites.

There is close to zero chance that existing comparison sites, at least right now since there is only 4 banks, with their existing product data ingest strategies, outside of direct JSON payload download, would be serving this content directly to consumer clients.

IF they are it would be done so within a Packaged SPA or Desktop/Mobile installed application (such as a mortgage broker application) where header control and processing can be more readily managed.

Further, in some high security environments CORS headers of */* may be explicitly blocked by corporate proxies and firewalls.

The accommodation of a public client paradigm for accessing the PRD data has always been intended (ie. accessing these APIs without the need for a server side implementation).

While the rules framework is not particularly explicit about HOW public data MUST be made available (ie. it doesn't demand direct browser loading only that a "means" such as an API is publicly available)

I have previously communicated that the resolution to this would be the mandating of dual serving at the same paths within CDR CA secured endpoints. This was proposed previously (somewhere in the multitude of feedback) but was rejected as "too much work" by Data Holders, a disputable assertion given the amount of other activities required of holders for implementation.

Finally, in September 2018 personnel responsible for the development of the Standards also were unsure of this requirement so "always been intended" appears to be inaccurate:

A final observation regarding CORS is that it is mainly relevant for direct API calls from the client. Some of the arguments presented are relevant for calls to the APIs directly from the browser or mobile client but less relevant for the more common use case of server to server calls supporting a long running authorisation. It is not yet clear if an implicit model will even be supported during the first phase. That said, the decision could go either way and could change in the future so it is not a point that would be definitive.

IF Product APIs must be made available to Public Unknown Clients the implementation effort to make them available via two endpoints (PublicBaseUri and ResourceBaseUri) appears to be significantly outweighed by the implicit degradation occurring on part of the ecosystem trust model.

[CDR-API-Stream]

This feedback mixes comments related to authenticated resource end points and unauthenticated end points. It also relates back to an issue that was consulted on and on which a decision was taken. Due to this it is difficult to extract from the feedback the specific content relevant to this question.

While the utility of a direct client model is open to opinion (ie. will anyone use this approach) it is still a valid scenario that could be of use. If data holders have any feedback indicating that the adoption of CORS would be problematic this feedback would be of value.

[perlboy]

This feedback mixes comments related to authenticated resource end points and unauthenticated end points. It also relates back to an issue that was consulted on and on which a decision was taken. Due to this it is difficult to extract from the feedback the specific content relevant to this question.

Then please reread and understand all referenced content. I've repeatedly stated Public != Unauthenticated. Maybe there is grounds to add an additional endpoint uri but the issue raised continues to remain the same.

The DSB appears to be confused within it's own responses especially as it's prior responses appear to increase the scope of this change outside of Product Reference Data to now include planned outages and status information, information typically associated with internal system statuses:

@CDR-API-Stream on October 31 2019:

the current recommendation for this change proposal is that the standards will require CORS for unauthenticated end points (including PRD, status and planned outages) but that this will not be required (above existing requirements included in normative references) for authenticated end points or security end points.

Such open disclosure of this information could introduce additional and currently not considered risks across Holder's with respect to hostile attackers being able to receive live feedback as to the effectiveness of their activities on Holders.

Additionally, such increase in scope of the PublicBaseUri also appears to overlap with the reporting processes promoted, and now mandated within Bank Operations teams, during the Payments System Board Update: May 2019 Meeting published 24 May 2019 where it stated:

It endorsed the Bank working with the industry and Australian Prudential Regulation Authority on a standard set of operational performance statistics to be disclosed by individual institutions.

Is the RBA and APRA integrated into the proposed reporting processes of the CDR?

While the utility of a direct client model is open to opinion (ie. will anyone use this approach) it is still a valid scenario that could be of use. If data holders have any feedback indicating that the adoption of CORS would be problematic this feedback would be of value.

Data Holders are impacted primarily by work effort. CORS has more explicit implications for Data Recipients and as per my first feedback: "As this is standards-maintenance is there a specific demand for this from participants? If so, where?"

[CDR-API-Stream]

This feedback is off topic and unhelpful. The DSB also believes it has been consistent in its response on these, and related topics.

The status and planned outage end points were always intended to be unauthenticated and have been stated as such since they were proposed. The standards currently document them as such. Data holders have not indicated that this position introduces any security issues either in public consultation or in workshops and bilateral meetings. The independent security review also did not highlight any concerns with this position.

This issue is purely related to the potential adoption of CORS into the standards. Further off topic feedback will be moderated.

[perlboy]

This issue is purely related to the potential adoption of CORS into the standards. Further off topic feedback will be moderated.

Ok it would appear @CDR-API-Stream has chosen to in-scope other areas then decided that responses to these included areas are off topic in nature.

This change is being misrepresented as aligning with FAPI Standard when it plainly does not. I ask the question for the third time:

As this is standards-maintenance is there a specific demand for this from participants? If so, where?

[CDR-API-Stream]

@perlboy, the feedback in this thread is coming across as antagonistic in nature and not in the spirit of the documented rules of engagement. It would be appreciated if you could refrain from making value oriented statements about the DSB in your feedback.

The question you have repeated was responded to in this comment https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/6#issuecomment-550075228

This change was not characterised as aligning to FAPI. FAPI was referenced in the context only. The change only proposed that CORS be adopted for the CDR standard.

[NationalAustraliaBank]

NAB has no security concerns with adopting CORS for unauthenticated, public endpoints (Get Status, Get Outages and Get Products endpoints).

[commbankoss]

Commonwealth Bank is supportive of requiring CORS for unauthenticated endpoints, but not for authenticated end points. However, we recommend that the change proposal provides more clarity as to where CORS will be required. It is worth considering closing this thread and opening a new issue where it is clear what would be the change.