slievrly commented on code in PR #7596:
URL: https://github.com/apache/incubator-seata/pull/7596#discussion_r2297851414
##########
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:
Security has to be the top priority, features come second. If a feature
doesn’t meet security standards, it shouldn’t be shipped. We need to ensure
safety in all known scenarios — security shouldn’t fail just because users
misconfigure something or skip settings. Giving users optional security
configurations is a bad idea; that choice shouldn’t be theirs. Thinking about
existing web servers: which ones actually follow this rule? If they do, does
that mean any security issues caused by user configurations become the user’s
fault, and the project avoids getting blamed for CVEs?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
