CORS headers verification and customization

[peterg79]

The application trust an arbitrary domain that is provided in the Origin header in cross-origin requests. The application does not validate the Origin header which can lead to data exposure when a malicious site embeds JavaScript to read or update data from the application. This can lead to a user’s data being leaked or changed without a user’s knowledge.

Additionally, the CORS Access-Control-Allow-Methods header is set to allow dangerous methods such as PUT and DELETE.

This can lead to a user’s data being leaked or changed without a user’s knowledge.

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[michael-mclawhorn]

This is not a bad set of changes, but I think we may want to get out of the business of providing default cors filtering. I'll review this PR, but we should consider feature-flagging the load of this filter in the ResourcesConfig

[cdeszaq]

Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- fili-core/src/main/java/com/yahoo/bard/webservice/web/filters/ResponseCorsFilter.java  2
         

See the complete overview on Codacy