无法通过“只读描述符”拦截恶意脚本对流式核心基类的直接破坏，因其仅防误写、不构成安全边界，且原生流类内部逻辑不受用户级冻结影响；有效防护需从防止XSS、隔离内容、启用Trusted Types、限制流权限四方面协同设防。
无法通过“只读描述符”拦截恶意脚本对流式核心基类的直接破坏。
原因很明确：JavaScript 中的 Object.defineProperty 或 Object.freeze 设置的只读属性（即 writable: false 的数据描述符），仅在运行时防止属性值被意外重写，它不构成安全边界，也不具备代码执行拦截能力。恶意脚本若已获得执行权（例如通过 XSS 注入、eval、innerHTML、setTimeout 字符串等），就能绕过所有描述符限制——因为描述符本身是 JavaScript 引擎层面的属性控制机制，不是沙箱或访问控制策略。
更关键的是，“流式核心基类”（如 ReadableStream、WritableStream、TransformStream）属于 Web 平台原生 API，其构造函数、原型方法和内部槽位（internal slots）不受用户级 Object.freeze() 影响。你冻结 window.ReadableStream，攻击者仍可：
- 用
new window.ReadableStream(...)正常创建实例 - 调用
.getReader()、.pipeTo()等方法（这些方法逻辑在引擎内部，不依赖可写属性） - 通过原型污染（若存在）或反射手段（如
Reflect.construct）绕过封装
真正有效的防护路径不是靠“只读”，而是切断恶意脚本的注入入口与执行上下文：
- 防止 XSS：对所有用户输入做输出编码（Razor 自动转义、
textContent替代innerHTML）、启用严格 CSP（禁用unsafe-inline/unsafe-eval、使用 nonce 或 hash） - 隔离不可信内容：用
<iframe sandbox></iframe>加载第三方富文本；对需渲染 HTML 的场景，强制使用DOMPurify.sanitize() - 启用 Trusted Types：声明
trustedTypes策略，让innerHTML、eval等高危 API 只接受经类型校验的TrustedHTML对象，从根本上阻断字符串拼接式 DOM 操作 - 限制流操作权限：避免将
stream.controller或底层underlyingSource暴露给不可信代码；敏感流逻辑放在 service worker 或 Web Worker 中隔离执行
简言之：描述符是开发辅助工具，不是安全机制。防御恶意脚本，必须从输入验证、输出编码、执行环境隔离、策略强制四个层面协同设防。
