Beyond Automation: 7 Web Vulnerabilities Best Found Through Manual Testing

Modern security testing relies heavily on automation, including DAST scanners, fuzzers and AI-powered tools. While these systems excel at detecting known patterns, they consistently fail when vulnerabilities depend on logic and context.

In this article, we'll explore seven web vulnerabilities that are notoriously hard to automate, explain why scanners miss them, and show where manual testing still has a decisive advantage.

Business Logic Vulnerabilities

A business logic vulnerability is a flaw in an application's core rules and workflows that allows attackers to misuse legitimate features for malicious purposes. It is often considered a goldmine for manual testers because they are hard to find by automated scanners. To find them, a tester needs to understand why the system behaves a certain way, not just how it behaves.

Business logic vulnerabilities depend on human intent and business rules; they are context-specific and often require a multi-step workflow to identify any logic error. Unlike vulnerabilities like _SQL Injection or XSS strings,_which have a fixed signature, automated scanners are unaware of the intended behavior or the context of the application.

Race Condition Vulnerability

A race condition is a problem that occurs when two or more actions attempt to use or modify the same data simultaneously, and the final result depends on which action finishes first. Because the system doesn't properly control the timing, it can lead to incorrect or unexpected results, such as selling the same item twice or charging the wrong amount.

The main challenge is that race conditions depend on timing. A vulnerability may only appear if two or more requests reach the server in a very specific order or at nearly the same time. Most automated scanners send requests sequentially or with generic concurrency, which often misses these narrow timing windows.

Modern tools can identify some race conditions, especially if they are designed for concurrency testing. However, these tools usually need:

• The correct target endpoints.
• Proper authentication.
• Tuned request timing and concurrency.
• Manual guidance from the tester.

Multi-Step Authorization Bypass

A multi-step authorization bypass is a security vulnerability where an application correctly checks a user's permissions at one step of a workflow, but fails to enforce those same permissions in a later step.

Authorization in multi-step flows (e.g., account registration, password reset, 2FA verification, or multi-page checkout) is stateful. Step 2 relies on a token, session variable, or database value created in Step 1. Scanners are notoriously bad at maintaining complex browser states across multiple pages without losing context.

Complex Access Control Vulnerabilities

Complex access control vulnerabilities arise from distributed system interactions, not simple endpoint bugs. These include temporal flaws — race conditions where authorization checks occur before asynchronous actions complete; cross-domain IDORs — manipulating object references that span internal databases and third-party integrations like Stripe or OAuth providers; and stateful logic breaks — where step order across multiple microservices violates intended business flow. These vulnerabilities don't exist in any single codebase — they emerge from mismatched assumptions between interconnected services.

Automated scanners and AI tools fail because they lack distributed state awareness. Scanners cannot maintain session context across multiple API gateways, complete third-party OAuth handshakes, or race asynchronous event queues. AI models, despite their reasoning capabilities, cannot execute code or track real-time state transitions across services. They predict text patterns linearly, but complex access flaws are non-linear, branching, and event-driven — requiring dynamic runtime exploration that neither scanners nor current AI architectures can perform.

Complex Cache Inconsistencies

Complex cache inconsistencies are security issues that occur when different caches (or different layers of the same cache) disagree about what data or permissions should be returned. This can lead to users seeing stale, incorrect, or even unauthorized information. It also occurs when multiple caches hold different versions of data or authorization state, causing applications to behave inconsistently.

A modern application may have several caches:

• CDN
• Reverse proxy
• Application cache (e.g., Redis)
• Database cache

Complex cache inconsistencies are difficult for AI (and many automated security scanners) to find because they often emerge from interactions between components over time, rather than from a single vulnerable piece of code. Detecting them requires understanding application behavior, infrastructure, and timing. An AI analyzing source code may only see the application logic, not the CDN configuration or reverse proxy rules. The vulnerability may only appear when these components interact.

Second Order Vulnerabilities

Second-order vulnerabilities are a class of security flaws where malicious input is submitted, saved (stored) by the application, and executed at a later time when the data is retrieved and used by the application or another user.

Common Types of Second-Order Vulnerabilities:

• Second-Order SQL Injection
• Stored Cross-Site Scripting (XSS)
• Second-Order Command Injection
• Second-Order Path Traversal

Second-order vulnerabilities are difficult for AI and automated scanners to detect because they span multiple requests, execution paths, and timeframes rather than a single interaction. Detecting them requires tracking data from its source to a later security-sensitive sink across databases, caches, background jobs, APIs, and user roles. They often depend on business logic, runtime state, data transformations, infrastructure configurations, and specific trigger sequences, making them challenging for both static and dynamic analysis to model and reproduce accurately.

AI/LLM Specific Indirect Prompt Injection

Prompt injection is a security exploit where a malicious user crafts an input (the "prompt") that tricks the LLM into ignoring its original system instructions and following the attacker's commands instead.

Indirect Prompt Injection occurs when the attacker does not type the malicious command into the chat themselves. Instead, they plant the malicious instructions in an external data source that the LLM will read later. The LLM cannot distinguish between legitimate data and the attacker's hidden commands. When the LLM processes that external data, it automatically "injects" the attacker's commands into its own context window and follows them.

Scanners and WAFs fail because Indirect Prompt Injection isn't a syntactic attack — it contains no malicious code, special characters, or known signatures for regex to catch. The payload isn't even in the user's HTTP request; it's fetched later from external data, bypassing perimeter defenses entirely. For the AI, distinguishing it is nearly impossible because LLMs treat all input text as equally valid instructions. The malicious command blends perfectly with benign formatting requests, and the model's inherent helpfulness compels it to obey any clear, logical instruction it reads.