手把手教你Nginx防护 CSP 内容安全策略之base-uri
HTTP Content-Security-Policy base-uri指令限制可以在文档<base>元素中使用的URL 。如果此值不存在,则允许使用任何URI。如果此指令不存在,则用户代理将使用该<base>元素中的值。
|
CSP版本 |
2 |
|---|---|
|
指令类型 |
Document指令 |
|
默认-src后备 |
不可以。 |
句法
基地政策可以允许一个或多个来源:
Content-Security-Policy: base-uri <source>;
Content-Security-Policy: base-uri <source> <source>;
来源
<source>可以是以下之一:
通过名称或IP地址的<host-source> Internet 主机,以及可选的 URL方案 and/or 端口号。该站点的地址可能包含一个可选的前导通配符(星号字符'*'),并且可以使用通配符(再次'*')作为端口号,表示所有合法端口对于源都有效。
示例:
http://*.example.com:匹配使用http:URL方案从 example.com 的任何子域加载的所有尝试。
mail.example.com:443:匹配所有尝试访问 mail.example.com 上的端口443的尝试。
https://store.example.com:匹配所有尝试访问 store.example.com 使用https:。
<scheme-source>一种模式,如'http:' 或 'https:'。冒号是必需的,不应使用单引号。您也可以指定数据模式(不推荐)。
data:允许将data:URI用作内容源。这是不安全的; 攻击者也可以注入任意数据:URI。谨慎使用这一点,绝对不适用于脚本。
mediastream:允许将mediastream:URI 用作内容源。
blob:允许将blob:URI 用作内容源。
filesystem:允许将filesystem:URI 用作内容源。
'self'指受保护文档的来源,包括相同的URL方案和端口号。你必须包括单引号。一些浏览器特别排除blob和filesystem从源指令。需要允许这些内容类型的网站可以使用Data属性来指定它们。
'unsafe-inline'允许使用内联资源,如内联<script>元素,javascript:URL,内联事件处理程序和内联<style>元素。你必须包括单引号。
'unsafe-eval'允许使用eval()和类似的方法从字符串创建代码。你必须包括单引号。
'none'指空集;也就是说,没有URL匹配。单引号是必需的。
'nonce- <base64-value>'使用加密随机数(使用一次的数字)的特定内联脚本的白名单。每次发送策略时,服务器都必须生成唯一的随机数值。提供一个无法猜测的随机数是非常重要的,因为绕过资源的策略是微不足道的。例如,查看不安全的内联脚本。
<hash-source>内联脚本或样式的sha256,sha384或sha512。生成散列时,不要包含<script>或<style>标记,并注意大小写和空白字符,包括前导或尾随空格。请参阅不安全的内联脚本。
“strict-dynamic”strict-dynamic源表达式指定显式给予标记中存在的脚本的信任,通过附加一个随机数或散列值,应该传播给由该脚本加载的所有脚本。与此同时,任何白名单或源表达式(例如'self'或'unsafe-inline'将被忽略)。有关示例,请参阅script-src。
示例
元标签配置
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
Apache配置
<IfModule mod_headers.c>
Header set Content-Security-Policy "base-uri 'self';
</IfModule>
Nginx配置
add_header Content-Security-Policy "base-uri 'self';"
复制
违规示例
鉴于你的域不是 example.com,使用<base>href设置为 example.com 的元素将导致CSP违规。
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
<base href="http://example.com/">
// Error: Refused to set the document's base URI to 'http://example.com/'
// because it violates the following Content Security Policy
// directive: "base-uri 'self'"
规范
|
规范 |
状态 |
评论 |
|---|---|---|
|
内容安全策略级别3该规范中'base-uri'的定义。 |
编辑草稿 |
没有变化。 |
|
内容安全策略级别2在该规范中的'base-uri'的定义。 |
建议 |
初始定义。 |
相关推荐
Nginx架构及配置详解
概述 Nginx采用C进行编写,是俄罗斯程序员开发的一款轻量级的可构建Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器的软件, Nginx服务器是一个高性能的HTTP和反向代理web服务器,同时也可提供了IMAP/POP3/SMTP服务。nginx常用作跑静态和做负载反向代理,动态php交给apache处理,因后者比较稳定,jsp交给tomcat、resin或jboss。n......
XSS攻击原理与防御实战:从弹窗到纵深防护体系
跨站脚本攻击(XSS)是一种常见的Web安全漏洞,其核心原理在于Web应用将不可信的用户输入未经充分处理便输出到页面,导致恶意脚本在用户浏览器中执行。从技术实现看,XSS利用浏览器对HTML、JavaScript等内容的解析机制,通过反射型、存储型和DOM型三种主要形式发起攻击。这种漏洞的技术价值在于它直接破坏了客户端的安全边界,使得攻击者能够窃取用户会话、篡改页面内容、实施键盘记录等,对用户数据和企业资产构成严重威胁。在应用场景上,XSS常见于搜索框、评论系统、用户资料等存在用户输入与展示的交互环节。针对
Debian 11 安装 Nginx 的完整实践指南:从校验到加固
Nginx 是 Linux 系统中最主流的 Web 服务器与反向代理软件,其核心价值在于高性能、低资源占用与模块化架构。理解 Nginx 的编译原理、模块依赖(如 OpenSSL、PCRE)及 systemd 集成机制,是实现稳定部署的前提。在 Debian 11 这类稳定发行版中,APT 仓库提供的 Nginx 版本(1.18.0)虽经安全加固,但存在功能缺失(如无 Brotli、无 TLS 1.3 ECH)、模块裁剪(禁用 perl/image_filter)和运行时约束(socket activati
Ubuntu 16.04 + GitLab + Let‘s Encrypt 全自动 HTTPS 部署实战
HTTPS 是现代 Web 应用的基础安全机制,其核心在于通过 TLS 协议实现传输加密与身份认证。Let’s Encrypt 作为免费、自动化、开放的证书颁发机构,依托 ACME 协议实现证书申请、验证与续期的全生命周期管理,显著降低 HTTPS 落地门槛。在 GitLab 这类自托管代码平台中,启用 HTTPS 不仅防范明文窃听(如密码、token、CI 变量泄露),更支撑 HSTS、OCSP Stapling、HTTP/2 等关键安全与性能特性。本文聚焦 Ubuntu 16.04 这一广泛使用的遗留环
uWSGI安全配置7大核心要点:从权限隔离到资源限制
在Web应用部署架构中,uWSGI作为连接Nginx与Python应用的关键组件,其安全配置直接影响整个系统的稳定性和安全性。遵循最小权限原则,通过创建专用系统用户运行uWSGI进程,可以有效限制潜在攻击的影响范围。采用Unix Socket替代TCP端口进行进程间通信,不仅能提升性能,还能通过文件系统权限实现更精细的访问控制。合理设置进程数、线程数及请求限制参数,可以防御资源耗尽型攻击,而环境变量加固与路径安全配置则能显著缩小攻击面。这些安全实践在Python Web应用部署场景中尤为重要,能够为Djan


