使用SonarQube对我们的Web应用进行静态代码分析，最近我也激活了JSP插件。 分析中提出了抱怨未封装表达式的问题，这是原代码的正确问题描述。
<!DOCTYPE html>
<html lang="${pageContext.request.locale}">抱怨第二行）。 SonarQube规则（findsecbugs-jsp:XSS_JSP_PRINT）给出了以下解释和潜在的解决方案。
Blockquote 发现了一个潜在的XSS。它可以被用来在客户端的浏览器中执行不需要的JavaScript。(参见参考资料)
漏洞代码。
<%
String taintedInput = (String) request.getAttribute("input");
%>
[...]
<%= taintedInput %>
解决方案。
解决办法：<%= taintedInput %>。
String taintedInput = (String) request.getAttribute("input");
%>.taintedInput = (String) request.getAttribute("input"); %>
[...]
<%= Encode.forHtml(taintedInput) %>
对XSS最好的防御就是像上面的例子一样，采用上下文敏感的输出编码。通常有4个上下文需要考虑。HTML、JavaScript、CSS（样式）和URL。请遵循OWASP XSS预防Cheat Sheet中定义的XSS保护规则，该规则对这些防御措施进行了详细的解释。
(findbugs规则也可以在以下网址找到 https:/find-sec-bugs.github.iobugs.htm#XSS_JSP_PRINT。).
虽然描述的情况与我原来的代码并不完全吻合（我用的是EL，例子用的是纯JSP），但我还是尝试着按照规则，将OWASP Java Encoder添加到我们的项目中。https:/owasp.orgowasp-java-encoderencoder-jspindex.html。 这是规则中提到的一个引用。
由此产生的代码看起来是这样的。
<%@ taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<!DOCTYPE html>
<html lang="${e:forHtmlAttribute(pageContext.request.locale)}">这与OWASP taglibs文档网站上的例子几乎完全吻合，而且似乎是正确的。
不幸的是，在再次运行SonarQube分析后，我在同一行得到了完全相同的问题（这次是新代码）。
谁能告诉我到底是什么触发了这个规则，以及代码应该是怎样的，才不会再引发这个问题？
记录一下。 我还用了e:forHtml而不是e:forHtmlAttribute，这更接近规则，但在这种情况下似乎不太合适。 甚至e:forHtml也留下了问题。
我使用的是SonarQube Community EditionVersion 7.9.1(build 27448)，内置FindBugs安全JSP插件。
非常感谢任何提示。
编辑：看来，不使用taglib，我可以让findbugs的逃逸被重新识别。 这可以工作，并且不再引起问题，但是我认为它很丑陋。
<%@ page import="org.owasp.encoder.Encode" %>
<!DOCTYPE html>
<html lang="<%Encode.forHtmlAttribute("${pageContext.request.locale}");%>">
这里只是一个想法。也许发生这种情况是因为它直接从用户输入中识别出渲染的HTML内容，即使你正确地转义了它。你能不能分两步来做？
e:forHtmlAttribute(pageContext.request.locale) <html lang= 内容干杯！