Direct vs. Indirect Prompt Injection

Hello! Welcome back to the course.

In our last lesson, we surveyed the landscape of LLM vulnerabilities using the OWASP Top 10 as our map. We focused on the LLM01 category, Prompt Injection, and created a taxonomy of different attack techniques that you will be building for your demo.

Today, we'll dive deeper into the most fundamental distinction within that category, addressing the learning outcome: Distinguish between direct and indirect prompt injection with concrete examples. Understanding this difference is not just academic; it's critical for threat modeling and designing effective, layered defenses. Direct and indirect attacks exploit different trust boundaries, have different victims, and require different security mindsets to prevent.

The Core Distinction: Who is the Attacker?

At its heart, the difference between direct and indirect prompt injection boils down to a single question: who is the attacker?

• In a direct injection, the user of the LLM application is the attacker. They are consciously crafting malicious input to send to the model.
• In an indirect injection, the user is the victim. The attacker is a third party who has placed a malicious prompt in an external data source, which the LLM then ingests on the user's behalf.

Let's begin with the official definitions from the OWASP project to establish a solid foundation.

To visualize this, consider the following diagrams. They illustrate the different data flows for each attack type.

This second diagram provides a similar flowchart view, which can also be helpful.

From your perspective as an SRE and automation engineer, you can draw an analogy to classic security vulnerabilities:

• Direct Injection is like a user typing '; DROP TABLE users; -- into a web form, a classic SQL injection. The malicious command is right there in the user's input.
• Indirect Injection is more subtle. It's like an application reading a configuration script from a seemingly legitimate S3 bucket, but an attacker has poisoned that script with a malicious rm -rf / command. The application executes the command, unaware of its malicious origin.

Direct Prompt Injection: Attacking the Front Door

In direct prompt injection, the attacker's goal is to subvert the LLM's primary instructions. They do this by crafting a user prompt that overrides or ignores the original system prompt.

Let's watch a practical example from a PortSwigger training lab.

In the video, the attacker simply asks the bot to delete the user. Because the LLM cannot reliably distinguish between a benign user query and a malicious instruction embedded in that query, it complies with the most recent, forceful instruction. The payloads you'll build, like basic instruction override ("Ignore previous instructions...") and jailbreaking, are all forms of direct injection.

Indirect Prompt Injection: The Hidden Threat

Indirect injection is far more insidious because it turns the application's features against its own users. The attack surface is no longer just the user input box; it's every single piece of external data the LLM might process.

Let's see this in action with another lab from the same video. Here, the vector is completely different.

This product review example is powerful. The attacker "poisons" a data source, knowing that the LLM will later retrieve and process it. This is precisely the threat model for the RAG component in your demo.

For a more sophisticated example demonstrating the business impact, let's look at an attack on an AI assistant that exfiltrates a user's private data.

RAG Poisoning: A Prime Example of Indirect Injection

The attack pattern of poisoning a data source is the specific vulnerability you'll be demonstrating with the RAG pipeline. An attacker can deliberately place malicious content in the documents that your RAG system will retrieve.

This article provides an excellent, detailed explanation of how RAG systems are targeted.

As the article explains, the attacker doesn't need to compromise your application's code. They only need to get their poisoned data into your vector database's source material. For your demo, this will involve placing a document with a hidden prompt into the directory that your RAG pipeline uses for context.

Summary: A Head-to-Head Comparison

Let's summarize the key distinctions in a table. This clarifies the different threat models and defensive considerations.

Conclusion

In this lesson, we dissected the critical difference between direct and indirect prompt injection. You've seen concrete examples of both and explored how indirect injection poses a particularly severe threat to modern LLM applications that integrate with external tools and data, like the RAG system you are building.

Key Takeaways:

• Direct Injection: The user is the attacker. The attack vector is the user prompt. The goal is to make the application break its own rules.
• Indirect Injection: The user is the victim. The attack vector is a poisoned external data source. The goal is to hijack the user's session to steal data or perform unauthorized actions.
• Architectures like RAG are prime targets for indirect injection, as they are designed to ingest and trust external content. Securing them requires treating all retrieved data as potentially hostile.

Next Up:

Now that we have a solid grasp of these attack patterns, our next step is to apply this knowledge to our vulnerable application. In the next lesson, we will perform a threat analysis of the chatbot we built, identifying its specific weaknesses against both direct and indirect injection. This analysis will form the basis for crafting our 10 targeted attack payloads in the modules that follow.