Brute Force

Systematically trying many credential, token, or code combinations against an endpoint until one succeeds - the general technique, rather than a specific bug in itself. Whether brute force is actually feasible against a given target depends entirely on whether the endpoint rate-limits or locks out repeated attempts, which is the real, directly testable question this category collapses into.

This is the same underlying question as Improper Restriction of Authentication Attempts: can an attacker send an unbounded number of guesses without being throttled? That's directly testable by bursting an endpoint and checking for a lockout/throttle response.

Bursting login, registration, and password-reset endpoints and checking whether any throttling response ever appears determines directly whether brute force is practical against a given target, without needing to run a full-scale attack to find out.

Tip: Because this weakness class is lower-volume and doesn't map to one of the standard high-frequency categories, it's typically found through general code review or a researcher's specific expertise rather than a repeatable, automatable technique.

Real-World Impact

Brute Force findings in disclosed reports typically lead to unauthorized access, data exposure, or disruption specific to the context this weakness appears in — the exact consequence depends heavily on where in the application the underlying flaw sits and what it touches.

Because this category doesn't map to one of the more specific, higher-volume weakness classes on this site, individual reports here tend to be evaluated on their own specific technical detail rather than against a broad, repeatable pattern — which is also why the fix is usually specific to the exact code path involved rather than a single universal control.

Organizations that treat lower-volume weakness categories as lower-priority by default risk missing exactly the kind of report that doesn't fit a common pattern but still carries real impact — triage by actual described severity, not by how common the category is.

Prevention and Secure Design

Preventing Brute Force takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Review the specific mechanism, not just the category label. Brute Force covers a specific technical pattern — understanding exactly what the disclosed report describes matters more here than applying a generic checklist.

Apply the closest relevant control family. Most weaknesses in this category share meaningful overlap with one of the higher-volume classes covered elsewhere on this site (injection, access control, cryptography, memory safety) — the detailed guidance for the closest match usually applies directly.

Have it reviewed by someone with the relevant specific expertise. A narrow or unusual weakness class often needs a reviewer with specific background in that exact area (cryptography, native code, protocol design) rather than general application security review.