Simple Bruteforce Bundle Laravel Package

Technical Evaluation

Architecture fit — Poor. SimpleBruteForceBundle is a Symfony bundle, not a Laravel package, and the distinction is not cosmetic. Its integration surface is Symfony-specific: a Bundle subclass registered in AppKernel, a DI Extension + CompilerPass for service wiring, and event subscribers bound to the Security component's security.authentication.failure / security.authentication.success events. Laravel has no bundle loader, no compiler pass pipeline, and its authentication stack (guards, Attempted/Failed/Login events, middleware pipeline) does not emit Symfony's security events. None of the wiring transfers. What is potentially reusable is the algorithm — attempt counting keyed on identifier, a fixed window, a lockout threshold, and a decay TTL — which is roughly 100 lines of code, not a dependency.

Integration feasibility — Low. Two paths exist and neither is "install the package":

1. Port the logic into a Laravel middleware plus an event listener, backed by Illuminate\Cache\RateLimiter. Estimated 1–3 engineer-days including tests.
2. Compose the same behavior from Laravel primitives already in the framework (RateLimiter facade, throttle: middleware, cache store).

Composer-level viability is also weak. A Symfony 3-era bundle will constrain symfony/* to ^2.8|^3.0 and likely php: >=5.5|^7.0. Current Laravel majors resolve Symfony 6/7 components. Forcing resolution with --ignore-platform-reqs to install a security control is an unacceptable trade — it produces an untested runtime combination and an unsupportable lockfile.

Technical risk — High.

• Abandonment. Symfony 3.4 reached end of security support in November 2018. A bundle targeting that line has had no framework security patching for roughly seven years.
• Security-sensitive surface. Brute-force protection sits directly in the authentication path. Unmaintained code in that path is a standing audit finding, independent of whether the code is currently correct.
• Zero validation signals. No stars, no dependents, no downstream users to surface regressions. There is no evidence of peer review.
• Unknown PHP 8.x compatibility. Nullable-type, dynamic-property, and string/array function signature changes across PHP 7→8 are common breakage points in this era of code.
• Unknown storage semantics. If attempts are stored via a Doctrine entity or a filesystem cache adapter, the lockout guarantee degrades silently under horizontal scaling (see Operational Impact).

Key questions to resolve before any further evaluation:

• What is the last commit date, and is the repository archived? Is the license permissive (MIT) and compatible with our policy?
• What are the exact composer.json constraints on php and symfony/*?
• Which storage backends are supported — cache pool, Doctrine ORM, or in-memory?
• How is the attempt key constructed? Is it IP-only, username-only, or a composite? Is X-Forwarded-For trusted?
• Is the failure behavior fail-open or fail-closed when the storage backend is unavailable?
• Does it ship tests, and has any CVE been filed against it or its dependency tree?
• Is there a maintained fork or a successor project from the same vendor?

Integration Approach

Stack fit — No direct fit. Every component maps onto a Laravel equivalent that we would have to build ourselves:

Migration path — None, by design. There is no incremental route from "Symfony 3 bundle" to "Laravel service provider." The realistic path is greenfield: read the bundle's algorithm and its configuration semantics (window length, threshold, decay, key composition), then implement equivalent behavior natively. Treat the repository as a design reference, not a dependency.

Compatibility — Blocking. Symfony 3 component constraints conflict with Laravel 9/10/11's Symfony 6/7 requirements. PHP constraint likely caps below 8.x. Both must be confirmed, but either one alone disqualifies direct installation.

Sequencing, if the capability is in scope:

1. Confirm the requirement — enumerate the auth surfaces needing protection (web login, API token issuance, password reset, OTP verification). These have different risk profiles and different key strategies.
2. Define the policy explicitly: threshold, window, lockout duration, per-identifier vs per-IP, and the escalation path for locked-out legitimate users.
3. Implement with RateLimiter + a throttle middleware on each surface, keyed on a composite of normalized username and client IP so that neither a single-account nor a single-IP attack slips through.
4. Instrument: emit metrics on lockout events, and alert on lockout rate spikes (both an attack signal and a false-positive signal).
5. Test adversarial cases — spoofed X-Forwarded-For, IPv6 normalization, distributed attempts across nodes, cache flush recovery.
6. Only then retire any existing ad-hoc throttling.

Recommendation: do not adopt the package. The build-vs-buy calculus fails on both sides — the buy option is an unmaintained, unvalidated, framework-mismatched dependency, and the build option is a few days against primitives we already own and already patch.

Operational Impact

Maintenance — Fork-and-own, with no upstream. Adopting this means permanently owning a vendored security component: PHP 8 upgrades, Symfony-constraint drift, and any future CVE response become our responsibility. That is a real ongoing cost against a 100-line algorithm.

Support — Effectively none. No vendor, no active maintainer, no community. Internal engineers unfamiliar with Symfony bundle idioms would be the only escalation path, which is an avoidable skills tax.

Scaling — This is the sharpest operational risk. Brute-force counters are stateful, and correctness depends on that state being shared and consistent:

• A file or array cache backend means each app instance counts independently. Behind a load balancer or autoscaler, an attacker gets N × threshold attempts and the control silently fails open. Redis (or another shared store) is mandatory.
• Cache eviction under memory pressure resets counters, granting an attacker a free window. Size the store and set TTLs deliberately.
• Counter key normalization matters at scale: IPv6 addresses need canonical form, and NAT'd corporate egress can put thousands of legitimate users behind one IP — IP-keyed lockouts will generate support tickets.

Failure modes to design for explicitly:

• Storage outage. Decide fail-open (attack succeeds, availability preserved) vs fail-closed (all logins blocked). Neither is free; fail-open with aggressive alerting is usually correct for consumer apps.
• Account-lockout DoS. Username-keyed lockout lets an attacker deny service to any known user by burning attempts against their account. Mitigate with CAPTCHA or progressive delay rather than hard lockout on the username dimension.
• IP spoofing. If client IP is derived from an untrusted X-Forwarded-For, the entire IP dimension is bypassable. This requires correct trusted-proxy configuration at the edge, not in application code.
• Clock skew / TTL drift. Window-based counters behave unpredictably across nodes with unsynchronized clocks if expiry is computed locally rather than by the store.

Ramp-up — Negative ROI. The team would spend more time learning Symfony 3 bundle conventions and debugging DI wiring than it would spend writing the equivalent Laravel middleware from scratch. Native implementation ramp-up is roughly one sprint-day for an engineer already fluent in Laravel's cache and auth layers.

Net position: the capability is worth having; this package is not the vehicle. The correct disposition is to close the evaluation, capture the bundle's configuration semantics as a reference for policy design, and implement the control natively on RateLimiter with a Redis-backed store.