Is there something more secure than "SHOULD use CORS"

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • Security
    • Security
    • 6.1.0.2
    • Hide

      Persuasive with mod

      Augment the sentence using the phrasing from the safety.html page – "Server: CORS ([cross-origin resource sharing

      http://enable-cors.org/]) is appropriately enabled (many clients are Javascript apps running in a browser)"

      therefore

      When it is desireable to support browser-based client applications, servers SHOULD consider CORS ([cross-origin resource sharing

      http://enable-cors.org/], W3c https://www.w3.org/TR/cors/, and https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/ ) is appropriately enabled (many clients are Javascript apps running in a browser)
      Show
      Persuasive with mod Augment the sentence using the phrasing from the safety.html page – "Server: CORS ([cross-origin resource sharing http://enable-cors.org/]) is appropriately enabled (many clients are Javascript apps running in a browser)" therefore When it is desireable to support browser-based client applications, servers SHOULD consider CORS ([cross-origin resource sharing http://enable-cors.org/], W3c https://www.w3.org/TR/cors/, and https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/ ) is appropriately enabled (many clients are Javascript apps running in a browser)
    • Kathleen Connor / Jim Kretz: 4-0-0
    • Enhancement
    • Non-substantive
    • STU3

      The requirement listed in this section allows the browser to make requests, putting it on par with other application platforms. However, a concern that has been raised during our risk analysis of the API Security is that a blanket "Allow all" list of CORS Domains is insufficient to prevent script-kiddy attacks, and that some stronger form of protection can and should be supported, which could benefit not just browser based FHIR applications but others as well.

      We'd like to see stronger guidance for securing an API Server deployed on the Internet from in appropriate access from unknown requesters, using something stronger than CORS Access-Control-Allow-Origin.

            Assignee:
            Unassigned
            Reporter:
            Keith W. Boone
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: