object标签无法限制PDF访问，因其仅加载资源且不携带认证信息；真正权限控制必须由服务端实现，如动态接口校验、签名URL、响应头防护等，前端措施仅具辅助性。
object 标签本身不提供任何文件访问权限控制能力——它只是个资源加载容器，没有鉴权、签名、会话校验等机制。
为什么不能靠 object 限制 PDF 或其他资源的访问
浏览器在解析 <object data="report.pdf"> 时，会直接发起一个无上下文的 HTTP GET 请求，不携带 Cookie（除非显式设置 crossorigin 且服务端允许）、不校验用户登录态、不执行 JS 权限逻辑。也就是说：
- 只要 URL 可被构造出来并能被浏览器访问，
object就会尝试加载 - 你无法在 HTML 层阻止未授权用户右键“另存为”或复制链接后直接访问
- 把 PDF 放在
/private/目录下，但没配服务端权限拦截，等于没保护
真正起作用的权限控制必须落在服务端
所有有效手段都绕不开后端配合，常见可靠做法包括：
- PDF 文件不暴露真实路径，用动态接口代理：比如
data="/api/pdf?docId=123"，后端在响应前校验 session / JWT / RBAC 规则 - 返回时设置一次性签名 URL（如 OSS 的
PostObject签名策略），URL 带过期时间与 HMAC，object加载时仍走该链接，但链接本身已绑定权限 - 服务端响应头强制加
Content-Disposition: inline+X-Content-Type-Options: nosniff，防 MIME 类型嗅探绕过 - 禁止目录浏览，且静态资源目录不映射到公网可直访路径（例如 Nginx 中禁用
location /pdfs/的 autoindex）
前端能做的只有辅助性防护（别当真）
这些操作对有心人基本无效，但可提高普通用户的访问门槛：
立即学习“前端免费学习笔记（深入）”；
- 用
typemustmatch属性防止服务端返回 HTML 冒充 PDF（避免 XSS 或跳转劫持） - 加载前用 JS 检查当前用户角色，若无权限则直接不渲染
object，改显示<p>无查看权限</p> - PDF 文件名用 UUID 或哈希代替业务含义（如
a7f2b9c.pdf而非salary-张三-2026Q3.pdf），降低信息泄露风险 - 不要在
data属性里拼接明文参数（如report.pdf?userId=123），这类 URL 容易被日志、代理、CDN 缓存捕获
最常被忽略的一点：哪怕你前端做了再多 JS 判断，只要服务端响应头没设 Content-Type: application/pdf 或返回了 200 + HTML 内容，object 就可能静默渲染出一个登录页甚至后台管理界面——权限校验永远不能只做在客户端。
