在Rack应用中，安全响应头并不是默认开启的。如果没有明确设置HSTS，浏览器仍然允许用户通过HTTP访问站点；如果缺少X-Frame-Options，攻击者可以把你的页面嵌入到自己的框架中实施点击劫持。Rack::SecureHeaders中间件正好用来集中管理这些安全头，避免在每个控制器或路由里重复编写响应头逻辑。
Rack::SecureHeaders来自secure_headers这个gem。它支持在Rack层面对多个安全相关响应头进行统一声明式配置，包括HSTS、X-Frame-Options、Content-Security-Policy等。下面先介绍如何安装并启用这个中间件，然后分别展开HSTS和X-Frame-Options的具体参数。
认识HSTS与X-Frame-Options安全头
HSTS的全称是HTTP Strict Transport Security，它通过响应头告诉浏览器：在指定时间内，对该域名的所有请求必须使用HTTPS，不能使用HTTP。这个机制可以有效阻止SSL剥离攻击，因为即使用户手动输入了http://，浏览器也会在发起请求前自动升级为https://。HSTS响应头的基本格式是Strict-Transport-Security: max-age=31536000; includeSubDomains; preload。其中max-age以秒为单位，31536000表示一年。includeSubDomains表示该策略同时作用于所有子域名，preload则意味着网站可以被提交到浏览器的HSTS预加载列表中。
X-Frame-Options用于控制页面是否允许被嵌入到<iframe>、<frame>、<object>等框架中。点击劫持攻击通常会在一个透明或半透明的框架中加载目标页面，诱使用户在不知情的情况下点击恶意按钮。通过返回X-Frame-Options: DENY可以完全禁止任何页面嵌入，而X-Frame-Options: SAMEORIGIN则允许同源页面嵌入，适用于需要在自身站点内部使用iframe的场景。需要注意的是，X-Frame-Options已经被现代浏览器逐步接受为一种基础防护，但更细粒度的控制建议使用Content-Security-Policy中的frame-ancestors指令。
在Rack应用中手动设置这两个头并不复杂，但会分散到多个地方。Rack::SecureHeaders的价值在于把安全头的配置集中到一个地方，同时提供默认值与环境差异化能力。下面我们来看具体代码。
使用Rack::SecureHeaders配置基础安全头
首先在Gemfile中加入secure_headers依赖，然后执行bundle install。对于纯Rack应用，可以在config.ru中直接使用中间件。以下是一个最小化配置示例：
# config.ru
require 'rack'
require 'secure_headers'
use Rack::SecureHeaders::Middleware do |config|
config.hsts = {
max_age: 31536000,
include_subdomains: true,
preload: true
}
config.x_frame_options = "SAMEORIGIN"
end
app = proc do |env|
[200, { 'Content-Type' => 'text/html' }, ['Hello Secure Headers']]
end
run app
上面的配置块中，config.hsts接收一个包含三个键的哈希。max_age是必选项，单位为秒，通常建议设置为至少半年以上，这里设置为一年。include_subdomains设置为true后，主域名下的所有子域名都会继承HSTS策略。如果某些子域名还在使用HTTP而没有有效的TLS证书，开启这个选项会导致这些子域名无法访问。preload设置为true只是在响应头中添加preload标记，并不代表已经加入浏览器预加载列表。要真正进入预加载列表，还需要在hstspreload.org上提交域名并通过审核。
config.x_frame_options的取值通常是"DENY"或"SAMEORIGIN"。字符串必须使用英文大写，因为响应头的值在协议层面是大小写不敏感的，但secure_headers在生成头时会原样输出。如果传入小写，浏览器也能识别，但保持一致更清晰。对于大多数不需要被第三方嵌入的站点，建议使用DENY；如果站点内部使用了iframe来展示自己的页面，则使用SAMEORIGIN。
完成配置后启动Rack应用，使用curl命令可以查看实际返回的响应头：
curl -I http://localhost:9292/
输出中应当包含Strict-Transport-Security: max-age=31536000; includeSubDomains; preload和X-Frame-Options: SAMEORIGIN。这里要注意，HSTS头只在HTTPS响应中才被浏览器接受。如果在开发环境中通过HTTP访问，curl仍然能看到响应头，但浏览器会忽略HSTS。因此测试时最好搭建一个本地的HTTPS环境，或者使用反向代理终止TLS后再检查。
不同环境下的配置策略与常见误区
生产环境与开发环境对安全头的需求并不一样。开发环境通常不需要HSTS，因为localhost没有有效的TLS证书，而且开启include_subdomains后还可能影响本地其他项目。secure_headers支持通过环境变量或判断RACK_ENV来生成不同的配置。以下示例展示了如何根据环境动态设置hsts和x_frame_options：
# config.ru
require 'rack'
require 'secure_headers'
use Rack::SecureHeaders::Middleware do |config|
if ENV['RACK_ENV'] == 'production'
config.hsts = {
max_age: 31536000,
include_subdomains: true,
preload: true
}
config.x_frame_options = "DENY"
else
config.hsts = false
config.x_frame_options = "SAMEORIGIN"
end
end
app = proc do |env|
[200, { 'Content-Type' => 'text/html' }, ['Hello Secure Headers']]
end
run app
当config.hsts被设置为false时，secure_headers会跳过该头，不会输出HSTS。这比设置一个很小的max-age更安全，因为max-age即使只有几秒，一旦浏览器记录后也会在短时间内强制HTTPS，可能在开发时造成困扰。类似地，config.x_frame_options也可以设置为false来完全禁用该头，但除非有明确理由，否则至少保留SAMEORIGIN。
一个常见的误区是认为设置了HSTS后就能立刻阻止所有HTTP请求。实际上HSTS依赖浏览器本地缓存，第一次访问如果通过HTTP进行，攻击者仍然可能在这个窗口期实施SSL剥离。要彻底解决首次访问的问题，需要将域名加入HSTS预加载列表，或者通过HTTPS的重定向来减少暴露。此外，HSTS的max-age过期之前，如果证书配置错误导致HTTPS不可用，用户将完全无法访问站点，并且没有任何浏览器界面可以绕过。因此开启include_subdomains和preload之前，必须确保所有子域名都具备有效的HTTPS证书。
X-Frame-Options也有一个值得注意的限制：它只支持DENY和SAMEORIGIN，以及已被废弃的ALLOW-FROM。ALLOW-FROM曾经可以指定一个具体的来源，但由于浏览器实现不一致且容易被滥用，现代浏览器已经不再支持。如果有更复杂的跨域嵌入需求，应该改用Content-Security-Policy的frame-ancestors指令。例如，允许来自ipipp.com的页面嵌入自己的站点，可以配置config.csp = { default_src: ["'self'"], frame_ancestors: ["ipipp.com"] }。注意这里的ipipp.com在真实环境中应根据自己的信任域替换，同时不要配置X-Frame-Options，否则两个头可能互相冲突。
验证与调试：如何确认安全头生效
配置完成后不能只看应用启动日志，必须实际检查响应头。除了前面提到的curl命令，浏览器开发者工具的Network面板也可以查看每个请求的响应头。在Chrome或Edge中，按F12打开开发者工具，切换到Network，刷新页面后点击主文档请求，在Headers区域找到Response Headers，确认Strict-Transport-Security和X-Frame-Options的值符合预期。
如果响应头没有出现，首先检查中间件是否被正确加载。对于Rack应用，中间件的顺序很重要，但secure_headers通常放在最前面即可。对于Rails应用，secure_headers会自动通过Railtie加载，但仍需在初始化文件中完成配置。可以查看应用启动时的中间件列表来确认，例如在Rails控制台执行Rails.application.middleware.include?(Rack::SecureHeaders::Middleware)。对于纯Rack应用，可以在config.ru中打印中间件栈或直接增加一个简单的响应头来测试。
另一个常见问题是HSTS头在HTTP环境下测试时看起来正确，但在HTTPS下却没有出现。这通常是因为反向代理或负载均衡器在转发请求时剥离或修改了响应头。如果你使用Nginx作为前端，需要在Nginx配置中确保不会覆盖应用返回的Strict-Transport-Security头，或者直接利用Nginx的add_header指令来统一设置。但同一响应头由应用和代理同时设置时，浏览器通常只会看到其中一个或合并，因此应选择一处维护，避免配置漂移。
最后，建议将安全头检查纳入自动化测试。可以在Rack::Test的集成测试中模拟请求，断言响应头包含预期值。例如：
require 'rack/test'
def app
Rack::Builder.parse_file('config.ru').first
end
def test_hsts_header
get '/'
assert_equal 'max-age=31536000; includeSubDomains; preload', last_response.headers['Strict-Transport-Security']
assert_equal 'SAMEORIGIN', last_response.headers['X-Frame-Options']
end
这类测试可以防止后续配置变更意外移除安全头。尤其在多人协作的项目中，安全头经常因为中间件顺序调整或配置重构而丢失，自动化断言能提前发现问题。
总结来说，Rack::SecureHeaders提供了一个轻量但完整的方案来管理HSTS和X-Frame-Options。配置时先明确站点的HTTPS覆盖范围，再决定HSTS的max-age和是否包含子域名；X-Frame-Options优先选择DENY，有同源嵌入需求时使用SAMEORIGIN。通过环境区分策略、避免在开发环境开启HSTS preload，并配合curl或自动化测试验证，可以让Rack应用的安全基线更加稳固。
Rack::SecureHeadersHSTSX-Frame-Options修改时间：2026-08-21 17:39:50