What is data execution prevention?
Data Execution Prevention (DEP) is a memory protection that stops a program from running instructions out of regions meant to hold only data. If an attacker exploits a memory bug and lands their own code in the stack or heap, DEP causes the processor to refuse to execute it. Like address space layout randomization, DEP does not repair the flaw that let the attacker write there; it blocks the simplest way of profiting from it.
How it works: the NX bit
DEP is enforced in hardware by the processor's NX (no-execute) bit, which marks pages of memory as non-executable. The operating system sets data regions, such as the stack and heap, as non-executable and code regions as executable. When the processor is told to execute an address inside a non-executable page, it raises a fault and the operating system terminates the process. Windows calls the feature DEP; Linux and others rely on the same NX capability. On older hardware a limited software-only version existed, but the real protection is the CPU bit.
The exploit it blocks, and the one it does not
DEP defeats the original overflow technique of injecting shellcode into a buffer and jumping to it, because that buffer now sits in non-executable memory. Attackers answered with return-oriented programming (ROP), which does not inject new code at all: it chains together small snippets of the program's own executable code to carry out the attack. ROP is harder to build, and ASLR makes it harder still by hiding where those snippets are, which is why DEP and ASLR are deployed together rather than alone.
Where it fits
DEP is one of the three platform protections to know alongside buffer overflows: DEP stops code running from data, stack canaries detect an overflow before a function returns, and ASLR randomizes addresses. None removes the bug; a memory-safe language and patching do that. The layered posture is to keep all three on and fix the code.
Data Execution Prevention on the CompTIA Security+ exam
In SY0-801, DEP belongs to the exploit-protection material: it is taught among the defenses against buffer overflows under objective 2.5, and among the exploit protections that blunt operating system vulnerabilities under objective 2.4. When a question asks how to reduce the risk from memory-corruption bugs, the scoring answers include DEP/NX, ASLR, stack canaries, memory-safe languages and patching. Recognize ROP as the technique that gets around DEP by reusing existing code.