@@ -76,6 +76,35 @@ To learn more from the source or to make advanced customizations, see:
76
76
77
77
78
78
79
+ [[webflux-cors-credentialed-requests]]
80
+ == Credentialed Requests
81
+ [.small]#<<web.adoc#mvc-cors-credentialed-requests, Web MVC>>#
82
+
83
+ Using CORS with credentialed requests requires enabling `allowedCredentials`. Be aware that
84
+ this option establishes a high level of trust with the configured domains and also increases
85
+ the surface of attack of the web application by exposing sensitive user-specific information
86
+ such as cookies and CSRF tokens.
87
+
88
+ Enabling credentials also impacts how the configured `"*"` CORS wildcards are processed:
89
+
90
+ * Wildcards are not authorized in `allowOrigins`, but alternatively
91
+ the `allowOriginPatterns` property may be used to match to a dynamic set of origins.
92
+ * When set on `allowedHeaders` or `allowedMethods`, the `Access-Control-Allow-Headers`
93
+ and `Access-Control-Allow-Methods` response headers are handled by copying the related
94
+ headers and method specified in the CORS preflight request.
95
+ * When set on `exposedHeaders`, `Access-Control-Expose-Headers` response header is set
96
+ either to the configured list of headers or to the wildcard character. While the CORS spec
97
+ does not allow the wildcard character when `Access-Control-Allow-Credentials` is set to
98
+ `true`, most browsers support it and the response headers are not all available during the
99
+ CORS processing, so as a consequence the wildcard character is the header value used when
100
+ specified regardless of the value of the `allowCredentials` property.
101
+
102
+ WARNING: While such wildcard configuration can be handy, it is recommended when possible to configure
103
+ a finite set of values instead to provide a higher level of security.
104
+
105
+
106
+
107
+
79
108
[[webflux-cors-controller]]
80
109
== `@CrossOrigin`
81
110
[.small]#<<web.adoc#mvc-cors-controller, Web MVC>>#
0 commit comments