Yes. In Rails, host checks run by default only in development. In production and other environments config.hosts is empty, so no Host header validation happens. Add your real domain names to config.hosts to guard against DNS rebinding and Host header attacks.
What the middleware does
ActionDispatch::HostAuthorization compares the request's host against an allow list. The Rails security guide recommends it against DNS rebinding and other Host header attacks. DNS rebinding changes which IP address a domain points to so that code from a hostile page can reach your app from a trusted looking origin. The configuration guide says it is on by default in development, and that in other environments you need to permit hosts yourself.
Host header attacks matter beyond rebinding. Apps that build links in emails, password reset messages or redirects from the incoming host can be tricked into pointing at an attacker's domain.
The setting
# config/environments/production.rb
config.hosts << "example.com"
config.hosts << ".example.com"
Entries can be strings, regular expressions or IP ranges. A leading dot allows the domain and all its subdomains. A regular expression is anchored, so it must match the entire hostname. A blocked request gets a 403 Forbidden response by default.
What can go wrong
| Problem | Cause | Fix |
|---|---|---|
| Blocked request page after deploy | Load balancer or health check uses another host | Add that host or exclude the path |
| Internal calls rejected | Service name not listed | Add the internal name |
| Review apps fail | Dynamic hostnames | Use a pattern for the preview domain |
| Everything allowed | config.hosts left empty | Add real hosts |
Health checks are the usual surprise. The configuration guide shows how to exclude requests from the check:
config.host_authorization = {
exclude: ->(request) { request.path.include?("healthcheck") }
}
That lets a health check path skip the host check without opening the rest.
Steps
- List every hostname that should reach the app: public domains, preview domains, internal service names.
- Add them to
config.hostsin production. - Add an exclusion for your health check path if the platform calls by IP.
- Deploy to staging first with the same list pattern.
- Watch for blocked host responses in logs.
- Check that email and redirect code does not trust the raw host header.
How it fits with other settings
Host authorization pairs with config.force_ssl = true, which forces HTTPS and adds the HSTS header. It does not replace authentication or CSRF protection. Think of it as a front door check on the name the request claims to be for.
Quick check
Is config.hosts on in production by default?
No. The Rails configuration guide says that in other environments it is empty and no Host header checks are done until you set hosts.
Does this stop all Host header attacks?
It blocks requests for unknown hosts. Your own code should still avoid building trusted URLs from the incoming header.
Safeguard's policy gates can fail a release when expected production settings are missing. A free scan is at gold.safeguard.sh/scan.
Sources
- Securing Rails Applications: DNS Rebinding and Host Header Attacks
- Configuring Rails Applications: config.hosts
Last reviewed: 19 October 2026.
