Weave Code
Firewall Laravel Package
kanopi/firewall
Kanopi Firewall is a lightweight PHP/Laravel package for controlling access by IP address. It offers configurable allow/deny rules and middleware integration to protect routes, block unwanted traffic, and manage firewall behavior from application configuration.
Library used for evaluating requests and if they should be denied.
Frequently asked questions about Firewall
- How do I install kanopi/firewall in a Laravel application?
- Install it with composer require kanopi/firewall, then publish the package configuration using Laravel's vendor:publish command and the tag shown in the README. Register the firewall middleware in your HTTP stack, define your allow and deny rules, and clear cached config before testing. Because the rules live in application configuration, you can commit environment-specific settings without editing web server files.
- How do I protect admin or staging routes by IP with kanopi/firewall?
- Apply the package middleware to the route group or controller routes you want to protect, then list the allowed IP addresses or CIDR ranges in the published config. This suits admin panels, staging sites, internal APIs, and other routes that should only be reachable from office or VPN addresses. Requests outside the allowlist receive the configured blocked response instead of reaching the route.
- Does kanopi/firewall support CIDR ranges and IP allowlists?
- Yes. The package provides configurable allow and deny rules for individual IP addresses and CIDR ranges, so you can express subnets rather than listing every host. The middleware evaluates those rules before the request reaches your route logic. Check the README for the exact config keys and evaluation order when you combine allow and deny entries.
- Can I customize the response returned to blocked requests?
- Yes, blocked-request responses are customizable through the package configuration, so you can return a specific status code, message, or redirect instead of a generic error. Keep the response simple and avoid revealing which specific rule matched. Confirm the available options in the published config file before relying on a custom response in production.
- Should I register the firewall middleware globally or per route?
- Both patterns are supported: you can add the middleware to specific route groups or register it globally for all HTTP requests. Per-route protection is usually better for admin areas and APIs, while global protection suits staging sites that should be closed to the public. Test global registration carefully so health checks, webhooks, and asset routes are not accidentally blocked.
- How do I manage different firewall rules per environment?
- Publish the config file and drive rule values from environment variables, or maintain separate config values per environment and let Laravel's config cache handle deployment. Avoid editing vendor files directly. After changing rules, run php artisan config:clear locally and config:cache in production so the middleware sees the new values.
- Which Laravel versions does kanopi/firewall support?
- Supported Laravel versions are defined in the package's composer.json illuminate/support constraint, so check that file and the README before installing or upgrading. As a middleware-based package it depends on Laravel's HTTP kernel and middleware APIs, which have changed across major framework versions. If you are on a newer Laravel release, confirm compatibility in your CI pipeline rather than assuming it.
- How do I test firewall rules safely without locking myself out?
- Start in staging, add your own IP to the allowlist, and test the protected routes before deploying. Write feature tests that assert allowed requests reach the route and blocked requests return the configured response, and remember tests use the test client IP rather than your browser's. If the app sits behind a proxy or CDN, make sure real client IP resolution is configured first. Also document an emergency bypass path, such as a temporary allow rule, for incidents.
- How does kanopi/firewall compare to a WAF or web server IP restrictions?
- A WAF or web server allow/deny rule blocks traffic earlier and can cover non-PHP assets, but it lives in infrastructure and varies by host. kanopi/firewall applies rules inside Laravel, so the rules travel with the application and can use framework configuration, but it only protects requests that reach PHP. Many teams use both: edge rules for broad blocking and application middleware for route-specific control.
- How is kanopi/firewall maintained, and what should I check before production?
- Review the repository's release history and issue tracker, pin a version in composer.json, and confirm the maintainers support your Laravel version before relying on it in production. Keep the published config in version control and treat firewall changes like any other access-control change, with review and rollback steps. For sensitive environments, monitor blocked-request behaviour after deploys and have a documented way to restore access quickly.
Weaver
How can I help you explore Laravel packages today?