Login Throttle Bundle Laravel Package

Product Decisions This Supports

• Credential-stuffing / brute-force protection as a compliance checkbox. Login throttling is a control auditors and security questionnaires ask about (OWASP ASVS 2.2.1, SOC 2 CC6.x, ISO 27001 A.8.x). This bundle lets you tick that box on Symfony services with configuration rather than custom code, which shortens security review cycles.
• Deprecated-dependency remediation. It exists explicitly to replace anyx/login-gate-bundle. If that package is anywhere in the dependency tree, this is a maintenance/risk-burndown decision, not a feature decision — the PM framing is "remove an unmaintained dependency," not "add a capability."
• Build vs. buy vs. configure. The real options are three, not two: (a) hand-roll throttling, (b) adopt this bundle, (c) configure Symfony's native login_throttling in security.yaml yourself (~5 lines). Because (b) is a thin preset over (c), the decision is low-stakes and reversible — that changes the approval bar. It should not consume roadmap capacity.
• Roadmap sequencing for an auth-hardening wave. Useful as a fast, shippable item ahead of larger identity work (MFA, SSO, session management, password policy). It buys a visible security win now without committing architecture.
• Scope fit for the long tail. Best value in legacy or low-traffic Symfony apps (internal admin panels, B2B back-offices, small customer portals) where a per-user/IP lockout with sane defaults is "good enough" and nobody will staff a bespoke rate-limiter.
• Laravel estate check (do this first). This is a Symfony bundle, not Laravel. If the product surface is Laravel, it does not apply — Laravel already ships RateLimiter / ThrottleRequests middleware. The PM action is to route this to the Symfony team or close it as not-applicable; do not let it enter a Laravel backlog as a "quick win."

Decision this most likely supports: "Adopt as a temporary, low-cost control and schedule removal-or-replacement at the next auth review" — not "standardize on this vendor."

When to Consider This Package

Consider it when:

• The stack is Symfony 6/7/8 on PHP 8.1+ (the bundle's stated support matrix) and you want default throttling values without designing them.
• You are migrating off anyx/login-gate-bundle and want an equivalent, drop-in-shaped replacement with minimal code change and no BC surprises in your login flow.
• You need standard, single-node login throttling in a low-to-moderate traffic app, and "per-username and per-IP attempt limits with a lockout window" meets the requirement.
• Your policy allows small, single-maintainer, MIT-licensed dependencies where the total code surface is small enough to audit in an afternoon.
• You want a cheap exit: because behavior is native Symfony config underneath, removal is a config edit rather than a rewrite.

Look elsewhere (or just configure natively) when:

• The product is Laravel. Not applicable. Use the built-in rate limiter.
• You need adoption-vendor confidence. Zero stars, zero dependents, and a single publisher are explicit signals: no community, no downstream validation, no implied support SLA. For a control on the authentication path — the highest-blast-radius code you own — that is a real consideration, not a nitpick.
• You need distributed / multi-node throttling. If you run several app instances behind a load balancer, in-memory attempt counters fragment and the effective limit multiplies by instance count. Look for a Redis/centralized-store-backed approach instead.
• You need composite or adaptive policy: per-account and per-IP and per-tenant, exponential backoff, progressive CAPTCHA, allow-lists for office/VPN ranges, device fingerprinting, "notify user of lockout" flows.
• You need observability and response: structured lockout events into SIEM/alerting, dashboards, or metrics on attack volume. This is a config preset, not a security telemetry product.
• You need a supported contract: procurement/enterprise contexts requiring a maintainer SLA, security-response commitments, or a CVE process. Nothing here provides that.
• You can already do it in five lines. If engineering confirms native login_throttling config covers the requirement, the correct answer is to not add a dependency at all — fewer moving parts on the auth path is strictly better. Make engineering prove the bundle adds something the framework doesn't.

Adoption gate to insist on: a named internal owner, a pinned version, a note in the dependency register explaining why it exists, and a one-line documented fallback ("if unmaintained, inline the native config and drop the bundle").

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a low-cost, low-risk way to close a standard security gap — automated lockout after repeated failed logins — and to retire a deprecated login-security dependency at the same time. It's a configuration-level change, not a platform commitment: it wraps a capability Symfony already provides, so if the package is ever abandoned we remove it by editing a config file rather than rewriting anything. I recommend approving it as a maintenance and compliance item this sprint, not as a roadmap initiative, and explicitly not standardizing on it as a strategic vendor. Cost is negligible; the benefit is a checked compliance control and one fewer unmaintained dependency on the authentication path.

For engineering (the actual ask):

• Confirm the stack is Symfony 6/7/8 / PHP 8.1+. If this is a Laravel service, stop — use the framework's rate limiter.
• First, evaluate the null option: can we meet the requirement with native login_throttling in security.yaml? If yes, do that and skip the dependency.
• If we adopt: pin the version, verify the configured defaults match our lockout policy (attempt count, interval, lockout duration) rather than trusting presets, and confirm behavior under multiple app instances — if we're load-balanced, native per-instance counters may not deliver the limit we're claiming to auditors.
• Add a focused test on the login path (lockout triggers, lockout expires, successful login resets the counter) and a short note in the auth runbook for support ("user locked out — here's how it clears").
• Record the exit path in the dependency register: replace with inline framework config if the package goes stale.

Risks to state openly, briefly:

1. Maintenance risk — single maintainer, no dependents, no community. Mitigated by the trivial exit path; unacceptable only if we require vendor support.
2. False sense of security — default throttling is one layer. It does not replace MFA, breached-password checks, or monitoring. Don't let "we have throttling" close the broader auth-hardening conversation.
3. Distributed-deployment gap — verify before citing the control in an audit.
4. Scope confusion — the most likely failure mode is a Laravel team picking this up by mistake. Route it to the Symfony owner.