What Are Logic Flaws in Application Security?

Pattern-based scanners catch the vulnerabilities that look wrong. They flag the SQL injection, the cross-site scripting, the hardcoded secret. But a growing class of serious vulnerabilities never looks wrong at all. The code is valid. It compiles, passes tests, and reads cleanly in review. The problem lives in what the code is supposed to do, not how it's written.

These are logic flaws, and they affect anyone shipping web applications, APIs, or multi-tenant services. They matter more now because AI coding agents generate code faster than any review cycle can keep up with, and that code frequently looks correct while quietly introducing flaws of exactly this kind.

What are logic flaws in application security?

Logic flaws are vulnerabilities that arise when syntactically valid code implements the wrong intent, letting an attacker abuse legitimate functionality rather than exploit a coding error. The flaw exists at the level of what the application permits, not in a malformed input or an unsafe function call.

Take an endpoint that fetches an invoice by its ID. The query is parameterized. The input is sanitized. Nothing in the code is unsafe. But if the endpoint never checks whether the requesting user actually owns that invoice, any authenticated user can read someone else's records by changing a number in the URL, as shown below. The code is correct. The intent is not.

@GetMapping("/invoices/{id}")

public Invoice get(@PathVariable Long id) {

  return invoiceRepo.findById(id); // no tenant check

}

HIGH  Authorization bypass through user-controlled key

CWE-639 · Broken access control · raised by SonarQube Hunter Agent

That's what separates a logic flaw from a pattern-based vulnerability. A SQL injection has a recognizable signature (a dangerous function, an unescaped input, a tainted data flow) that a scanner can match against. A logic flaw has no signature. It's working code enforcing the wrong rule, and knowing that requires reasoning about the application's intended behavior across its full context.

What are the three categories of logic flaws?

Logic flaws cluster into three categories. Broken access control and authentication/session flaws are both named risk categories in the OWASP Top 10 (A01:2021 and A07:2021, respectively). Business logic abuse isn't a standalone OWASP Top 10 category; it falls under the broader Insecure Design category (A04:2021), since it exploits a workflow's intended rules rather than a coding defect. Each category abuses a different trust assumption and maps to its own set of CWE weaknesses.

Broken access control

Failures to enforce what an authenticated user is allowed to do. The most common form is IDOR: an app exposes an internal reference, like a database key in a URL, without checking that the requester is authorized to use it. Related failures: privilege escalation and missing authorization checks.

  CWE-639    CWE-862    CWE-863    CWE-285    CWE-269  

Business logic abuse

Exploiting the intended rules of a workflow rather than a defect in the code. Skipping a required step, stacking a coupon meant to be used once, hammering an endpoint with no rate limit. Each individual request is well-formed, so nothing looks like an attack.

  CWE-840    CWE-841    CWE-799    CWE-770  

Authentication & session flaws

Gaps in how an app establishes and holds a user's identity. Session fixation, sessions that never expire, weak password-recovery flows, missing MFA where it's warranted. The login mechanics are present, but an attacker can assume or retain an identity they shouldn't have.

  CWE-287    CWE-384    CWE-613    CWE-640    CWE-308  

Why are logic flaws so hard to detect?

Logic flaws resist automated detection because the thing that makes them dangerous, correct-looking code, is the same thing that makes them invisible to pattern matching.

A static analysis scanner works by recognizing patterns: it traces tainted data from a source to a dangerous sink and flags the match. That works well against injection flaws, because they have a shape. A logic flaw has no shape to match. The code is syntactically valid, uses safe functions, and would pass any signature check. The vulnerability exists only at the level of intent, and intent isn't something a pattern can encode.

To know that the invoice endpoint above is vulnerable, an analyzer has to understand that invoices belong to tenants, that this user belongs to a different tenant, and that no check connects the two. Confirming that means following data and identity flows across many files to reconstruct what the application is supposed to enforce. That's a reasoning problem spanning the full codebase, not a lookup against a rule set.

How do teams find these flaws today?

Because scanners miss them, teams lean on human-driven methods that apply reasoning the tools can't. Each one works for the same reason, and strains for the same reason.

Manual code review

An engineer reads every change and reasons about intent: whether an authorization check is missing, whether a workflow step can be skipped.

Penetration testing

Security specialists probe the running application for abusable logic, typically on a periodic, often twice-a-year, cadence.

Threat modeling

Teams map out how an application could be attacked before code is written, identifying where access control and workflow enforcement need to hold.

Bug bounty programs

External researchers are paid to find and report exploitable logic in production, crowdsourcing the search for a fee.

Every one of these methods depends on scarce, expensive human attention. None of them runs continuously at the speed code now ships.

Why current approaches fall short against AI-generated code

These methods were calibrated for a world where code was written at human speed. AI-generated code breaks that assumption, and each method strains in a different way: manual review can't keep pace with pull-request volume, and a twice-a-year pentest leaves everything shipped in between unchecked.

Source: Sonar 2026 State of Code Developer Survey; Carnegie Mellon University research on AI coding tool adoption.

The deeper problem is that AI coding agents lack security context. They generate code that looks correct and passes tests, but frequently omits the check that would have stopped it: the missing tenant check, the absent rate limit, the authorization step that was never written. This produces AI verification debt: the widening gap between how fast code is generated and how fast its intent can be verified. Threat modeling and bug bounties help, but neither closes a gap that grows with every agent-authored pull request.

How SonarQube Hunter Agent helps

SonarQube Hunter Agent is an AI-powered security agent built to hunt the intent-based vulnerabilities traditional static analysis was never built to catch: broken access control and IDOR, business logic flaws, and authentication and session gaps. These aren't broken code. They're correct code that does the wrong thing, which is exactly why they slip past pattern-based scanners.

It works through playbooks, the way a security researcher works a code audit: curated, multi-step sequences of security prompts that encode Sonar's application security expertise.

• Hunt: explores the full codebase and follows data and identity flows across files, building hypotheses about where intent and implementation diverge.
• Confirm: investigates and validates every suspected vulnerability before it surfaces, producing high-precision findings instead of a queue of false positives.
• Explain: each finding arrives with a severity, a plain account of why it matters, and the exact location in code.
• Integrate: confirmed findings land in your SonarQube issue list, tagged and ready to triage, assign, and fix.

Hunter Agent complements, not replaces, SonarQube's SAST and SCA analysis. Static analysis covers what can be traced in code; Hunter Agent covers what can only be found by reasoning about intent. Together, they form a layered, zero-trust verification approach across 19 CWE classes.