File Inclusion (LFI and RFI) is a vulnerability where an application loads files based on attacker-influenced input. Local file inclusion can expose server files, while remote file inclusion can load attacker-controlled code or content. Defenders should enforce strict allow lists, canonicalise paths, and prevent user input from controlling file targets.
What File Inclusion Means in Practice
File inclusion becomes dangerous when an application turns user-controlled input into a file path or URL and then loads that target at runtime. The core weakness is not the include statement itself, but the trust placed in data that should never decide what code or content is fetched.
local file inclusion, or LFI, points the application at files on its own server. That can expose configuration files, source code, logs, or other sensitive data if path handling is weak. remote file inclusion, or RFI, goes further by allowing attacker-controlled remote content to be fetched and executed or interpreted, which can turn a content-loading flaw into code execution.
These issues often appear in templating systems, language-specific include functions, plugin loaders, debug endpoints, and poorly constrained “page” or “template” parameters. The vulnerability is especially severe when the application assumes a filename is a harmless selector, but the underlying runtime treats it as an instruction.
Why File Inclusion Is So Abusable
File inclusion is attractive to attackers because it sits on the boundary between input handling and runtime behaviour. If an attacker can influence a file target, they may be able to read sensitive local files, trigger parser quirks, load unintended resources, or chain the flaw with upload, traversal, or log poisoning issues.
RFI is usually the higher-impact variant because it can allow externally hosted payloads to be included as executable content. LFI is often used for disclosure first, then escalation through log files, session files, temporary files, or other writable paths that can be turned into executable input.
The severity depends on how the language and framework handle inclusion semantics. In some stacks, inclusion means direct code execution; in others, it means dangerous parsing, rendering, or disclosure. Either way, the common failure is the same: attacker influence over a file target creates an unacceptable trust boundary breach.
How Organisations Check Exposure
Exposure assessment starts with finding every place the application resolves file paths from request data, cookies, headers, form fields, or derived values. Teams should review route handlers, template resolution logic, plugin and module loaders, import helpers, and any code that conditionally includes files by name.
Asset inventory matters because vulnerable inclusion points are often scattered across old endpoints, admin tools, or legacy components that are easy to overlook. Internet-facing services deserve priority, especially where inclusion is reachable without authentication or where low-privilege users can influence the target path.
Vendor advisories and secure coding guidance are also useful because many frameworks have specific safe patterns for path resolution, allow-listing, and sandboxing. For a broader view of how web application weakness patterns cluster together, see the Web Application Attacks Guide.
Defence, Detection, and Recovery
Defence begins by removing the attacker’s ability to choose arbitrary targets. Applications should use strict allow lists, map friendly names to server-side file identifiers, and canonicalise paths before any access decision is made. Where possible, avoid dynamic inclusion altogether and replace it with fixed routing, explicit configuration, or safer lookup tables.
If a patch cannot be applied immediately, compensating controls should reduce both reachability and blast radius. That usually means restricting file-system permissions, isolating the application process, blocking outbound fetches where remote inclusion is even theoretically possible, and hardening logging and temporary-file locations that could be abused as inclusion targets.
Detection should look for suspicious path traversal markers, unexpected remote fetches, repeated probing for common local files, and anomalous requests that target template or language-specific include parameters. After remediation, teams should review logs, uploaded files, temporary directories, and exposed source paths for signs that the flaw was already used to read data or stage code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | File inclusion is a secure design flaw in how applications resolve and load paths. |
| V13 — Configuration | Safe include handling depends on restrictive, well-defined application configuration and path controls. | |
| Recommendation — Refactor inclusion logic so user input cannot directly control file targets or execution flow. Lock configuration so only approved local resources can be resolved at runtime. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This control set covers secure application design and testing where file inclusion flaws are found. |
| Recommendation — Test include and path-resolution code paths for unsafe user-controlled file access before release. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | RFI can be used to fetch attacker-hosted content into a target environment. |
| T1059 — Command and Scripting Interpreter | Exploited inclusion flaws can lead to code execution through scripting or interpreter abuse. | |
| Recommendation — Monitor and block unexpected remote retrievals that may deliver malicious payloads. Hunt for interpreter abuse when file inclusion exposes executable content paths. | ||
Practitioner Guidance
What to watch for: Treat any parameter that selects a page, template, language resource, or filename as a security-sensitive input, even if the feature looks harmless. The safe design pattern is to resolve user intent to a server-side identifier, not to pass user input directly into the filesystem or a remote fetch routine.
Governance implication: File inclusion issues are easiest to prevent when secure coding standards require allow-listing, path canonicalisation, and explicit bans on remote inclusion primitives. Ownership should sit with the application team that controls the inclusion logic, because the defect is usually architectural rather than operational.
Practitioner takeaway: If a user can influence the target of an include, treat that path as untrusted until proven otherwise, and assume that disclosure, code execution, or chained exploitation may already be possible.
Related resources from NHI Mgmt Group
- What breaks when SQL injection and local file inclusion are not controlled?
- What is the difference between path traversal and local file inclusion in web application attacks?
- Why does an arbitrary file inclusion flaw on an internet-connected gateway create such high risk?
- How should security teams test file upload and download paths for local file inclusion risk?