Topic starter
02/08/2026 11:57 am
TL;DR: Broken access control has remained OWASP’s top web application risk through 2025, while a separate business logic category was created because syntactic defenses do not catch intent failures; Gecko Security’s BSides London companion piece argues LLMs can reason through those gaps where traditional tools cannot, according to Gecko Security. The shift matters because modern code generation and microservice sprawl are increasing the number of places where authorization assumptions quietly fail.
Editorial analysis by NHI Mgmt Group, based on content published by Gecko Security: “Business Logic Is AppSec's Unsolved Problem”.
By the numbers:
- Broken access control remained OWASP’s number one web application risk in the 2025 release, while injection fell to fifth place.
- Optus exposed 10 million user records in 2022, roughly a third of Australia’s population.
Key questions
Q: What breaks when business logic controls are tested only with pattern-based tools?
A: Pattern-based tools miss intent failures because they look for known code shapes, payloads, or signatures.
Q: Why do broken access control issues keep ranking above other web vulnerabilities?
A: Because authentication can succeed while authorization still fails.
Q: What are the signs that authorization logic is failing?
A: Common signs include repeated role-check branches, inconsistent decisions between services, manual exceptions, and difficulty explaining why a user could act on a specific object.
Practitioner guidance
- Instrument authorization-flow testing for semantic abuse Add review steps that trace how users, tenants, and service accounts move through business workflows, with explicit checks for missing or inconsistent authorization decisions.
- Prioritise high-value logic paths for AI-assisted review Focus LLM-based analysis on endpoints, workflows, and call chains where a single access-control failure would expose many records, tenants, or privileged actions.
- Verify object-level and group-level access enforcement Check whether identifiers, invitation flows, forking actions, and tenant boundaries are enforced consistently across the application, not just at the front door.
Bottom line: Business logic vulnerabilities persist because they break intent, not syntax, so the controls that defeated injection do not solve the new problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:05 pm
Business logic is now the decisive blind spot in application security. Injection was reduced by making invalid syntax harder to express, but intent failures cannot be eliminated by pattern matching. That means traditional secure-development controls are necessary but no longer sufficient when authorization itself is the thing under attack. Practitioners should treat semantic abuse as a first-class testing category, not an edge case.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams use LLMs for business logic testing without overtrusting them?
A: Use LLMs to accelerate code reading, path tracing, and hypothesis generation, then validate every candidate flaw with human context and manual verification. The model should reduce search time, not replace judgement about business intent, exploitability, or impact.
👉 Read our full editorial: LLMs are changing how teams find business logic vulnerabilities