Local File Inclusion (LFI) is a web vulnerability that allows an attacker to trick an application into including or reading files that already exist on the target server, but which the attacker should not be able to access. It arises when an application dynamically includes files based on user-supplied input without properly validating or sanitizing that input. If an attacker can control which file path the application includes, they can direct it to read sensitive local files – such as configuration files, password files, source code, or logs – leading to information disclosure and, in some circumstances, code execution.
The vulnerability typically appears in applications that build file paths from parameters. For example, a page might load content using a parameter like ?page=home, constructing a path such as /var/www/pages/home. If the application does not restrict what the parameter can contain, an attacker can supply a path-traversal payload – using sequences like ../ to move up the directory tree – to reach files outside the intended directory, for instance targeting a system file like /etc/passwd. Because the included file resides on the same server (hence “local”), LFI reads local content, in contrast to Remote File Inclusion, where an application is tricked into including a file from an external, attacker-controlled source.
The consequences of LFI can be serious. At minimum, it enables disclosure of sensitive files, exposing configuration secrets, credentials, application source code, or system information that aids further attacks. In more severe cases, LFI can be escalated to code execution – for example, by including a file into which the attacker has managed to place malicious code (such as poisoned log files, uploaded files, or session files), causing the server to execute it. This escalation can turn an information-disclosure flaw into full compromise.
LFI is fundamentally a failure to properly handle untrusted input used in file operations, and it is closely related to path traversal and to the broader injection family. It matters in the API and web-application context because any endpoint that reads or includes files based on client input is potentially exposed.
Preventing LFI requires never trusting user input in file paths: validating input strictly against an allowlist of permitted values rather than accepting arbitrary paths, avoiding the direct use of user input to construct file paths, sanitizing input to neutralize traversal sequences, using safe APIs that do not include files based on raw input, applying least-privilege file-system permissions so the application can access only what it needs, and disabling dangerous features that allow inclusion of arbitrary files. The core principle is to constrain file access to a known, safe set of resources and to treat any user-supplied file reference as untrusted.