Product Decisions This Supports
- Pre-launch and staging access gating — restricting a new environment, beta, or internal tool to a known set of IPs until SSO or full auth is ready. This is the single most common PM-relevant use case, and it is a temporary control, not a permanent one.
- Admin/back-office perimeter hardening — a cheap second lock on
/admin or /horizon for teams that cannot yet front those routes with a VPN or identity-aware proxy.
- Compliance and licensing carve-outs — evidence of network-level restriction for auditors, or enforcing regional availability constraints (e.g., a partner contract limiting access to specific corporate ranges).
- Incident response kill-switch — a fast, reversible way to narrow the blast radius of an active abuse event before a WAF rule or CDN change is approved.
- Build vs. buy signal — the existence and abandonment of packages like this is itself a decision input: it tells you IP filtering is a ~50-line middleware concern, not a product category worth a dependency. Route the roadmap item to "build in-house" and spend the budget on a real edge/WAF layer instead.
- What it does not support — this is not a WAF, not rate limiting, not bot detection, not geo-blocking at scale. Do not let it appear on a roadmap as a security control that satisfies a threat model beyond static allow/deny lists.
When to Consider This Package
Consider only in these narrow cases:
- You have inherited an application that already depends on it, and you need a short, time-boxed decision on whether to rip it out now or at the next planned refactor. (Answer: plan the removal, don't extend it.)
- You are reading it as a reference implementation — its IP-matching and trusted-proxy logic is a useful sanity check for what your own middleware must handle.
- A throwaway internal spike where the environment is not internet-reachable and the blast radius of a flaw is effectively zero.
Look elsewhere — decisively — when any of the following is true:
- New build. The package is marked DEPRECATED and the repository is archived, with no release since October 2019. That predates multiple PHP and framework major versions. There is no security response path: no CVE process, no maintainer, no patch. A dependency with no one on call is an unowned risk on your register.
- It is load-bearing for security. An archived allowlist library sitting in front of an admin panel is a single point of failure that no one is watching. If the requirement is genuinely security-relevant, the correct owner is the edge: CDN/WAF rules, a VPN, an identity-aware proxy, or network policy — not application code.
- You sit behind a load balancer, CDN, or reverse proxy. Correct client-IP resolution and trusted-proxy configuration is exactly the class of logic that rots when a package is unmaintained, and getting it wrong silently turns an allowlist into a bypass or a lockout.
- You need IPv6, CIDR ranges, dynamic rule sources, geo data, or audit logging. Assume none of this is maintained; verify before assuming it exists at all.
- Supply chain policy applies. Archived, low-adoption (62 stars), single-maintainer dependencies are increasingly flagged by automated dependency governance. Expect to justify it in review and lose.
The realistic alternative: framework-native middleware plus the platform's throttling and routing primitives, or an edge provider rule set. A focused allow/deny middleware with explicit trusted-proxy configuration is on the order of tens of lines, fully owned, and testable — and it does not require a deprecation migration later.
How to Pitch It (Stakeholders)
To executives (one paragraph): A vendor package was proposed for IP-based access restriction. It is officially deprecated, its repository is archived, and it has had no release since 2019 — meaning no security patches and no maintainer accountable if it fails. The capability it provides is small and can be built and owned internally at low cost, or bought as part of an edge/WAF provider we already pay for. Recommendation: do not adopt; fund the small in-house implementation or fold the requirement into the existing edge security contract. The risk avoided is an unowned, unpatched component in an access-control path — cheap to prevent now, expensive to explain later.
To engineering (the ask): Do not add m6web/firewall as a new dependency. Build a small, tested allow/deny middleware owned by the team, with explicit and documented trusted-proxy/client-IP resolution, IPv4 and IPv6 CIDR support, config-driven rule sets per environment, and structured logging on every deny. Treat the package only as a reference for edge cases. If it is already in the codebase, add a ticket to replace it at the next scheduled work cycle — do not wait for a refactor that has no date. Flag any place it is currently the only control protecting an admin surface; those need an interim compensating control (VPN or edge rule) this sprint, not next quarter.
Framing for the roadmap review: this is not a "adopt a library" decision, it is a "who owns this control" decision. The answer should never be "an archived repository."