Thanks for opening this pull request! 🎉 Please check out our contributing guidelines. If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

Walkthrough

Adds a new hostauthorization middleware: implementation, configuration, documentation, README index entry, and comprehensive tests/benchmarks that enforce Host header allowlisting (exact, leading-dot wildcard, CIDR, dynamic validator) and rejection via a configurable error handler.

Changes

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Client as Client
  participant App as Fiber App
  participant HA as HostAuthorization
  participant Store as AllowedHostsStore
  participant Func as AllowedHostsFunc
  participant Err as ErrorHandler

  Client->>App: HTTP request (Host header)
  App->>HA: invoke middleware
  HA->>HA: normalize Host (strip port/brackets/trailing dot, lowercase)
  HA->>Store: check exact / wildcard / CIDR matches
  alt matched
    Store-->>HA: allowed
    HA->>App: c.Next() -> downstream handler
  else not matched
    HA->>Func: if configured, call AllowedHostsFunc(host)
    alt func returns true
      Func-->>HA: allowed
      HA->>App: c.Next() -> downstream handler
    else
      HA->>Err: call ErrorHandler(c, ErrForbiddenHost)
      Err-->>Client: 403 Forbidden (or custom response)
    end
  end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

• ReneWerner87
• sixcolors
• efectn

Poem

🐇 I hop through headers, trim brackets and dots,
I check wildcards, CIDRs, and exact little spots,
If hosts are true I let them pass on through,
If naughty hosts knock, I say “403, shoo!” 🥕

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.28%. Comparing base (ce8d2a9) to head (32c78a6).
⚠️ Report is 11 commits behind head on main.

@@            Coverage Diff             @@
##             main    #4199      +/-   ##
==========================================
+ Coverage   91.22%   91.28%   +0.05%     
==========================================
  Files         123      125       +2     
  Lines       11892    11971      +79     
==========================================
+ Hits        10849    10928      +79     
  Misses        655      655              
  Partials      388      388              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for the contribution @mutantkeyboard , DNS rebinding protection is a valid concern and I appreciate the thorough work on docs and tests.

Before we move forward, I want to raise a design question: should this be a standalone middleware or an extension of the existing Domain() router?

Domain() already matches requests by host pattern at the routing level. Adding an allowlist/deny semantic there (e.g. app.SetAllowedHosts(...)) would:

• Avoid the overhead of an extra handler in the middleware chain on every request
• Make the relationship between host-based routing and host-based security explicit
• Keep host logic in one place instead of two separate systems

If we do keep it as a standalone middleware, a few things need addressing:

Performance

• ~3,200 ns/op with 25 allocations is too high for a middleware that runs on every request. The core of this is a map lookup + a few string comparisons, that should be near-zero alloc. The wildcard suffixes should be stored with the leading dot at init time (as already flagged in reviews), and normalizeHost() should be applied to config values at init, not just at request time.
  You can use the utils package or existing functions from the other middlewares

API / Consistency

• Missing Exclude field , our other middlewares expose this hook, and this one should too for consistency.
• normalizeHost() not applied to configured hosts during init - this can lead to subtle mismatches (e.g. MyApp.com in config vs myapp.com at runtime).

Documentation

• The CIDR section reads like source-IP filtering ("respond to requests from known IP ranges"). This needs to clearly state it matches the Host header value, not the client IP. As written, someone could deploy this thinking they have IP-based access control, which
  would be a security misunderstanding.

Scope question

• CIDR matching on the Host header is a fairly niche use case; in practice, Host headers rarely contain raw IPs outside of internal tooling. Is the complexity worth it, or would exact match + subdomain wildcards cover 99% of real-world usage?

I'd like to hear your thoughts on the Domain() integration angle before we iterate further on the middleware approach. Either way, the normalization logic and test coverage you've built here is solid and would carry over.

Hey @ReneWerner87, thank you for the review.

Regarding Domain() integration

I'm genuinely curious what did you have in mind there. My original inspiration for this was brannondorsey/host-validation, which is explicitly a standalone
middleware for DNS rebinding protection on Express. The pattern just felt like a natural fit here too — Domain() is opt-in per route and calls c.Next() on non-match, so it doesn't have global reject
semantics. CIDR and leading-dot wildcards would also need special-casing since parseDomainPattern doesn't support either today. That said, if you see a clean way to integrate it without blurring routing and
access control, I'm open to it.

Performance

The 3,200 ns/op and 25 allocations are from app.Test()

• that overhead belongs to Fiber's request pipeline, not this middleware per se. The actual per-request cost is a map lookup, a couple of string ops, and one real alloc: the "."+suffix concat in the wildcard path. Fixing that (storing the leading dot at init) plus switching to utilsstrings.ToLower in normalizeHost gets the common path to near-zero alloc.
  I'm more than happy to add a lower-level benchmark that isolates just the matching logic so the numbers are less misleading.

normalizeHost at init

This one is actually a good catch - config entries with trailing dots won't match runtime-normalized hosts. Easy fix.

CIDR docs

This is actually a fair point. I can fix the wording to make clear it's matching the Host header value, not the client IP.

But regarding the overall architecture, I can integrate it into the existing Domain() or leave it as a separate middlware. It's really up to you and @gaby

WDYT?

ok

Go ahead with the leading-dot fix at init + normalizeHost on config entries, that alone should clean up the hot path nicely. And yes, please add an isolated benchmark for just the matching logic so we have real numbers for the middleware cost without app.Test() noise.
Fix the CIDR docs wording as discussed.
On CIDR scope: keep it for now. It's not a lot of extra code and internal tooling with IP-based hosts is a real enough use case. We can always revisit if it causes maintenance headaches down the line.

pls also try the utils functions for the better performance

@ReneWerner87, am I crazy or it seems like fasthttp 1.7.0 has broken multiple packages with stuff like Host header in HTTP/1.1 , fs.FS handling and Cache-Control?

@ReneWerner87, am I crazy or it seems like fasthttp 1.7.0 has broken multiple packages with stuff like Host header in HTTP/1.1 , fs.FS handling and Cache-Control?

@ReneWerner87 @mutantkeyboard the PR for fasthttp was merged with failing tests. They added a bunch of security fixes that conflict with our security checks.

@mutantkeyboard Test failures are now related to the new middleware.

@gaby - I will fix that today

@gaby - this is now fixed. 💪💪

Given the current implementation and the distinct purposes, I recommend keeping hostauthorization as a separate middleware rather than integrating it directly into the Domain() router or Ctx helpers.

Here's why:

• Separation of Concerns: The hostauthorization middleware serves a security function (DNS rebinding protection), while Domain() is primarily for routing. Keeping these concerns separate leads to a cleaner, more modular architecture. As the PR description states, hostauthorization acts as a "security gate" and Domain() as a "routing layer."
• Flexibility: A standalone middleware can be applied globally, to specific groups, or conditionally, offering greater flexibility to users regardless of their routing strategy. Tying it to Domain() might limit its applicability.
• Domain() Limitations: As @mutantkeyboard pointed out in comment [🐞] Found 3 gosec issues: CWE-78 and CWE-242 #5, Domain() is opt-in per route and lacks the global reject semantics needed for a security middleware. Additionally, parseDomainPattern in Domain() does not currently support CIDR ranges or leading-dot wildcards, which are core features of this host authorization middleware. Integrating these would add complexity to the router that might not align with its primary function.
• Current Review Direction: The recent discussions (e.g., comment Add deprecated alerts, linting, nosec, typo's #6 from @ReneWerner87) have focused on optimizing the standalone middleware's performance and refining its documentation, implicitly affirming the current design choice.

Therefore, maintaining it as a dedicated middleware seems to be the most robust and flexible approach for this security feature.