Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-3677

T257: Secure cross origin resource sharing (CORS)

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False

      Story (Required)

      Use the following guidelines for securing CORS:

      Do not rely on the {{Origin:}} header for access control.
      * Enforce a normal authentication/authorization process.
      ** Same-origin requests and non-browser requests are not subject to a CORS policy
      ** See the related How-to for this countermeasure on CORS and access control.
      * Perform authentication/authorization for all request types such as GET and POST, except OPTIONS.
      * Make sure no part of the functionality that is not public is exposed without authentication.

      Use standard procedures to block cross-site request forgery (CSRF).
      * See the related How-to for this countermeasure.

      Use the following guidelines to develop a secure CORS policy, using a whitelist for trusted origins.
      * Do not send CORS response headers on private resources that are not intended to be used across origins
      * Send the wildcard value (Access-Control-Allow-Origin: *
      ) in a response containing publicly accessible resources

        • It is recommended to enable this for all public resources, including JavaScript files, stylesheets, and images. Doing so enables features such as Subresource Integrity and HTML5 canvas exports.
        • As a precaution, the wildcard cannot be used with credentials (cookies, client certificates

      Background (Required)

      Refer to the Epic description.

      Out of scope

      Any previous counter measures.

      Approach (Required)

      - Discuss this issue in the bug triage or cabal.

      Dependencies

      NA

      Acceptance Criteria (Mandatory)

      • Bring this issue to the bug triage call and take a decision on the counter measure.
      • If further discussion is needed, bring this issue to the cabal.

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

              Unassigned Unassigned
              aveerama@redhat.com Abhishek Veeramalla (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: