YvCeung commented on code in PR #7596:
URL: https://github.com/apache/incubator-seata/pull/7596#discussion_r2297554145
##########
server/src/main/java/org/apache/seata/server/filter/XSSHttpRequestFilter.java:
##########
@@ -60,21 +59,17 @@ public class XSSHttpRequestFilter implements
HttpRequestFilter {
Pattern.CASE_INSENSITIVE);
public XSSHttpRequestFilter() {
- String xssKeywordConfig =
CONFIG.getConfig(SERVER_HTTP_FILTER_XSS_FILTER_KEYWORDS, null);
-
- if (StringUtils.isBlank(xssKeywordConfig)) {
- this.xssKeywords = DEFAULT_XSS_KEYWORDS;
- } else {
- ObjectMapper objectMapper = new ObjectMapper();
- try {
- xssKeywords = objectMapper.readValue(xssKeywordConfig, new
TypeReference<List<String>>() {});
- } catch (JsonProcessingException e) {
- throw new IllegalArgumentException(
- "Invalid format for configuration
'server.http.filter.xss.keywords'. "
- + "Expected a JSON array like [\"<script>\",
\"vbscript:\"], but got: "
- + xssKeywordConfig,
- e);
- }
+ String xssKeywordConfig =
CONFIG.getConfig(SERVER_HTTP_FILTER_XSS_FILTER_KEYWORDS, DEFAULT_XSS_KEYWORDS);
Review Comment:
> Why do we need user configuration? Do users need to learn such details? If
users configure wrongly, does it mean we can't provide secure services?
Security is not an option. At all times, the services we provide must be secure.
Ultimately, this comes down to a trade-off between prioritizing security and
prioritizing flexible configuration. I believe it should be evaluated on a
case-by-case basis. For example, when it comes to XSS protection, itโs
impossible to anticipate every potential attack pattern. In such cases,
allowing users to update configurations themselves enables a quick response to
emerging threats. However, some scenarios must always prioritize security, such
as enforcing HTTPS. Users should not be allowed to disable HTTPS for
convenience, as doing so could expose all traffic to man-in-the-middle attacks.
In situations like this, security measures should be enforced by default rather
than left as a configurable option.๐
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@seata.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@seata.apache.org
For additional commands, e-mail: notifications-h...@seata.apache.org
