使用EL表达式将JSP后端数据传递给JS变量的最佳实践

在传统的 Java Web 开发中，将后端存储在 request、session 中的数据传递给前端 JavaScript 是一项极其常见却极易出现安全隐患的需求。直接在 <script> 标签内拼接 var val = "${data}"; 看似简单，实则面临 XSS 跨站脚本攻击、引号中断报错、换行符引发语法崩溃以及复杂对象无法序列化等严重问题。本文将深入剖析 JSP 与 JS 的执行生命周期差异，并系统介绍行业推崇的三大安全落地范式：HTML5 data-* 属性传递、独立 application/json 数据块 以及 基础类型的严格内联转换。

一、核心机制与认知误区：生命周期的本质隔离

许多初学者之所以在传递数据时频繁遇到诡异的语法错误，根本原因在于混淆了服务端模板渲染与客户端脚本执行的先后时序。JSP 并不是直接与 JavaScript “通信”，而是经过编译执行后生成一段纯文本 HTML 响应流交付给浏览器。

图 1：JSP 服务端模板解析与客户端 JavaScript 执行生命周期时序

从生命周期可以看出，当浏览器收到页面时，所有的 ${...} 表达式已经被完全替换为对应的字符。如果在这个过程中不对字符的内容做安全限定与边界处理，就会产生严重的代码缺陷。

二、常见的反模式与安全隐患

在不规范的代码库中，往往存在以下四种典型错误写法：

1. 字符串未转义与引号逃逸引发语法崩溃

<!-- 危险反模式 -->
<script>
  let userAddress = "${user.address}"; 
</script>

如果用户的地址中包含双引号（例如 Room 102, "Sunshine" Building），JSP 替换后的实际代码将变成：

let userAddress = "Room 102, "Sunshine" Building"; // 语法错误：Uncaught SyntaxError: Unexpected identifier

2. 包含未处理换行符导致脚本中断

JavaScript 的普通字符串字面量（使用单双引号包裹）不允许跨行。若后端传递的富文本或备注字段含有换行符 \n，输出为多行文本后，浏览器在解析第一行结束时便会抛出 Invalid or unexpected token。

3. XSS 跨站脚本注入（高危漏洞）

这是最致命的安全缺陷。假设 userName 来自外部输入，攻击者构造恶意字符串：

"</script><script>alert(document.cookie)</script>

浏览器在进行 HTML 解析时，优先级最高的是 </script> 结束标签。哪怕该字符串被包裹在双引号内部，解析器也会立即闭合当前脚本段并执行攻击者注入的恶意脚本，造成会话劫持。

4. 复杂对象直接输出触发 toString() 陷阱

<!-- 错误做法：直接传递 List 或 Map -->
<script>
  let userList = ${userList}; // 展开后为：let userList = [com.example.User@4a5e2]; 产生语法报错！
</script>

EL 表达式遇到非基本数据类型时，默认调用对象的 toString() 方法。Java 对象的内存地址或普通字符串表示根本不是合法的 JavaScript 数组或对象字面量。

三、推荐实施的三大最佳实践方案

最佳实践一：利用 HTML5 data-* 属性解耦（推荐首选）

现代前端开发极其推崇“行为与表现分离”。通过将后端数据输出为 DOM 元素的 data-* 自定义属性，不仅天然享有 HTML 属性编码的保护，还能让 JavaScript 逻辑完全迁移到独立的 .js 外部文件中，消除内联脚本。

服务端 JSP 编写规范：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<!-- 将数据挂载在容器标签上，利用 c:out 强制进行 HTML 实体转义 -->
<div id="userProfile"
     data-user-id="<c:out value='${user.id}' />"
     data-user-name="<c:out value='${user.name}' />"
     data-is-admin="<c:out value='${user.adminRole}' />"
     style="display: none;">
</div>

前端 JavaScript 读取规范（可在独立的 app.js 文件中）：

document.addEventListener("DOMContentLoaded", function () {
  const profileEl = document.getElementById("userProfile");
  if (!profileEl) return;

  // 1. 读取字符串（dataset 自动将连字符属性映射为驼峰命名）
  const userId = profileEl.dataset.userId;
  const userName = profileEl.dataset.userName;

  // 2. 基础类型按需还原
  const isAdmin = profileEl.dataset.isAdmin === "true";

  console.log("用户信息加载完成:", { userId, userName, isAdmin });
});

最佳实践二：复杂对象与集合采用 application/json 隔离传递

如果后端需要一次性传递包含上百条记录的列表、嵌套树形结构或多维配置，直接拆分多个 data 属性显得力不从心。此时应当在控制层或工具类将数据转换为标准 JSON 字符串，并放置在 <script type="application/json"> 标签内。

为什么是 application/json？浏览器在解析 DOM 时，如果 <script> 的 type 为非执行类型（如 application/json），JS 引擎不会将其当做代码去编译执行，从而完全规避了可执行脚本注入风险。

1. 后端 Controller 准备：

// 使用 Jackson ObjectMapper 将复杂实体转为 JSON 字符串
ObjectMapper mapper = new ObjectMapper();
String permissionsJson = mapper.writeValueAsString(permissionService.getUserRules(userId));

// 注意：对可能存在的 </script 进行转义处理
permissionsJson = permissionsJson.replace("</", "\\u003c/");
request.setAttribute("permissionsJson", permissionsJson);

2. JSP 页面模板：

<%-- 隔离的数据孤岛，外部不可直接执行 --%>
<script type="application/json" id="server-permissions-data">
  ${permissionsJson}
</script>

3. 前端读取并安全反序列化：

function loadServerPermissions() {
  const dataScript = document.getElementById("server-permissions-data");
  if (!dataScript) return null;

  try {
    const rawText = dataScript.textContent.trim();
    return rawText ? JSON.parse(rawText) : null;
  } catch (error) {
    console.error("服务端权限配置解析失败:", error);
    return null; // 给予安全默认值
  }
}

const userPermissions = loadServerPermissions();

最佳实践三：简单数值与布尔类型的严格内联转换

在少数情况下，页面必须在内联脚本中立即使用简单的控制变量（例如分页游标、开关标识）。此时如果直接使用 EL 表达式，必须做到类型显式包装与三元表达式空值兜底。

<script>
  // 1. 数值类型：强制通过三元表达式保障默认值，并用 Number() 包装
  const pageSize = Number("${not empty param.pageSize ? param.pageSize : 20}");
  const currentTotal = Number("${not empty recordCount ? recordCount : 0}");

  // 2. 布尔类型：直接通过严格布尔比较返回 JS 原生布尔值
  const isFeatureEnabled = ("${featureEnabled}" === "true");

  // 3. 必须内联简单字符串时：利用 c:out 进行转义或调用工具函数
  const userRole = "<c:out value='${user.role}' default='GUEST' escapeXml='true'/>";
</script>

四、标准化实施流程与生命周期衔接

为了保证团队协作中的代码质量，推荐按照以下四步标准流程实施后端数据向前台的传递：

图 2：JSP 数据注入前端 JavaScript 变量的标准四步闭环模型

五、方案选型矩阵与决策依据

为了帮助工程师在不同业务场景下做出最优技术决策，我们对三种主要传递策略在安全、复杂度、性能和维护性四个维度进行了全面对比：

图 3：三种主流后端传递方案在安全、复杂性与解耦度的全景对比

为了进一步明确在具体开发场景中的技术决策路径，请参照下方的决策树流程：

图 4：面向复杂场景的 JSP 到 JS 变量传递工程决策树

六、防御性编码与常见异常兜底清单

在实际编码中，还需特别警惕极端边界情况。以下清单给出了针对性防范指南：

• 防御空指针（Null Safety）：当后端数据未初始化或查询为空时，EL 表达式默认返回空字符串 ""。在需要布尔或数值的地方，务必在 JSP 中使用 JSTL 三元运算符给出安全默认值（如 ${not empty count ? count : 0}）。
• 防范闭合标签截断：在 application/json 数据块中，若 JSON 字符串内部恰巧包含 </script>（例如富文本内容），HTML 语法解析器会无视 MIME 类型强行闭合该标签。后端序列化时，应统一将 </ 替换为 Unicode 转义字符 \u003c/。
• 字符集一致性：确保 JSP 页面头部声明了 <%@ page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %>，避免中文字符在 EL 替换时因服务端默认编码不一致出现乱码，进而导致前端变量初始化异常。
• 统一反序列化封装：在前端公共工具库中建立标准读取函数，对所有 JSON.parse 统一包裹 try...catch，并在捕获到异常时记录监控日志并返回空对象或预置结构，避免单个数据解析失败导致整个页面脚本崩溃。

七、总结

在 JSP 与 JavaScript 交互的历史演进中，直接内联拼接变量的做法早已被现代 Web 工程淘汰。将 HTML5 data-* 属性 作为基础键值传递的标准容器，将 <script type="application/json"> 作为大型复杂对象传递的数据孤岛，不仅能够从根源上杜绝 XSS 注入与脚本解析错误，更能使前端脚本从臃肿的 JSP 页面中解耦，真正实现静态资源的独立部署、缓存与自动化构建。