Prevent file inclusion: LFI, RFI, dynamic imports and template names

An application has a file inclusion flaw when input decides which file, module or template it loads and interprets. CWE-98 names the PHP case: a request parameter reaches include or require. Local file inclusion (LFI) points the include at a file already on the server, often with ../ path traversal; remote file inclusion (RFI) points it at a URL the attacker controls. Because the loaded file is executed or rendered rather than just read, the impact is usually worse than plain path traversal.

PHP made the bug famous, but every platform has a loader that does the same thing when given a name built from input. The table lists the common sinks and the effect of controlled input.

This router appends .php and assumes that limits the damage. It does not. The parameter accepts ../ segments, and PHP's stream wrappers change how a target is read. One old trick is gone: since PHP 5.3.4 a path containing a NUL byte is invalid, so a %00 suffix no longer strips the extension.

<?php
// Vulnerable: the request decides which file PHP includes.
$page = $_GET['page'] ?? 'home';
include __DIR__ . '/pages/' . $page . '.php';
// ?page=../../vendor/some/file      -> includes a different PHP file

A first proof of concept often just prints a system file, which tempts teams to rate an LFI as information disclosure. That underestimates it. Because an included file is executed, the real question is whether an attacker can influence the contents of any file the include can reach. On real systems that is common, so default to treating a PHP LFI as remote code execution when you triage it.

• Uploaded files stored where the application can include them are the most common route, which is why upload storage location matters so much.
• Server-side stream wrappers (for example php://filter) change how a target is read, so defenses that only inspect the apparent file name are incomplete.
• Files that record request data, such as logs and session files, let an attacker influence content indirectly.
• The reachable set grows with configuration: an unset open_basedir and an includable upload directory each widen it.

Keep the set of includable files in code. The request supplies a key; the map supplies the path. Nothing from the request reaches include, so there is no encoding, wrapper or traversal to defend against.

<?php
// Fixed: input selects a key; only paths written here can be included.
const PAGES = [
    'home'    => __DIR__ . '/pages/home.php',
    'pricing' => __DIR__ . '/pages/pricing.php',
    'contact' => __DIR__ . '/pages/contact.php',
];

$key = $_GET['page'] ?? 'home';
if (!is_string($key) || !array_key_exists($key, PAGES)) {
    http_response_code(404);
    exit;
}
require PAGES[$key];

An allowlist only works if it checks the same string the include uses. phpMyAdmin 4.8.0 and 4.8.1 checked a decoded, truncated copy of the target parameter against a list of allowed pages, but passed a different value to include; a crafted value passed the check while the include resolved to other files (CVE-2018-12613, PMASA-2018-4, fixed in 4.8.2). The advisory notes that a restrictive open_basedir greatly limited what attackers could read, which is exactly the backstop role it should play.

The lesson generalizes. Decode input once, validate the decoded value, and use that same value (ASVS 5.0.0 1.1.1). Better still, don't validate a path at all: look the key up in a map and use the map's value.

• Keep allow_url_include off (the default). It is INI_SYSTEM, so code cannot turn it on at run time, and it was deprecated in PHP 7.4.
• Turn allow_url_fopen off when no code path needs file functions to read URLs; fetch remote data with an HTTP client instead.
• Set open_basedir to the application's own directories so an LFI cannot read /etc or other applications' files.
• Store uploads outside the web root and outside every include path, under generated names, and configure the web server never to execute PHP in upload directories (ASVS 5.0.0 V5.3.1).
• Log and alert on parameters containing php://, data://, phar://, expect:// or long runs of ../, which are rarely legitimate.

Node.js resolves a specifier the same way whether you wrote it or the attacker did. A locale or plugin name joined into a path accepts ../ segments and absolute paths, so it can load any .js, .json or native .node file the process can read, including an uploaded one. Dynamic import() is broader: Node.js supports data: URLs with the text/javascript MIME type, so in a test on Node.js 26.3.0, import("data:text/javascript,export default process.version") ran supplied code with no file on disk.

// Vulnerable: the specifier is built from, or is, request data.
export async function loadLocale(lang) {
  return (await import(`./locales/${lang}.mjs`)).default; // ../ escapes the folder
}

export async function loadPlugin(name) {
  return (await import(name)).default; // a data: URL runs supplied code
}

A map from key to a function with a literal specifier keeps every loadable module visible to reviewers and bundlers. Check membership with Object.hasOwn so inherited keys such as __proto__, constructor and toString are rejected; in a test, all three were.

// Fixed: input selects a key; each specifier is a literal in the source.
const LOCALES = {
  en: () => import("./locales/en.mjs"),
  fr: () => import("./locales/fr.mjs"),
  de: () => import("./locales/de.mjs"),
};

export async function loadLocale(lang) {
  if (typeof lang !== "string" || !Object.hasOwn(LOCALES, lang)) {
    throw new RangeError("unsupported locale");
  }
  return (await LOCALES[lang]()).default;
}

importlib.import_module(name) imports whatever module the name resolves to and runs its top-level code. With a name from a request, an attacker can import modules you never meant to expose, or run code they managed to drop onto an import path. Register plugins explicitly in a dict, or load them through installed package entry points (importlib.metadata.entry_points), which only exposes code an administrator installed.

from importlib.metadata import entry_points

# Vulnerable: importlib.import_module(request.args["exporter"])

# Fixed: only exporters installed as packages, selected by a registered name.
EXPORTERS = {ep.name: ep for ep in entry_points(group="reports.exporters")}


def get_exporter(name: str):
    entry = EXPORTERS.get(name)
    if entry is None:
        raise LookupError("unknown exporter")
    return entry.load()

Jinja2's FileSystemLoader refuses names containing a .. segment, so render_template("../app.py") raises TemplateNotFound. That does not make a user-chosen name safe. In a test with Flask 3.1.3 and Jinja2 3.1.6, a help endpoint that rendered request.args["page"] with a secret in its context served admin/debug.html, which printed the secret. Any template in the folder becomes reachable, with whatever variables the vulnerable view passes. The same applies to {% include name %} when name comes from data. ASVS 5.0.0 1.3.7 asks that templates are never built from untrusted input.

from flask import Flask, abort, render_template, request

app = Flask(__name__)

# Vulnerable: render_template(request.args["page"], ...) renders any template.

HELP_PAGES = {
    "billing": "help/billing.html",
    "security": "help/security.html",
}


@app.get("/help")
def help_page():
    template = HELP_PAGES.get(request.args.get("page", ""))
    if template is None:
        abort(404)
    return render_template(template)

In Spring MVC, a @Controller method's String return value is a view name. With Thymeleaf, the view is resolved by parsing the name as a fragment expression, so a name built from input becomes expression injection. Veracode's research documented that a controller returning a view name concatenated from a request parameter can lead to code execution, and that methods returning void can be affected too because Spring then derives the view name from the request path.

Return data with @ResponseBody or @RestController, choose views from a fixed set, and keep request data out of redirect: targets as well, which otherwise become open redirects. Thymeleaf's Spring integration now rejects view names that appear in the request, but published bypasses such as CVE-2021-43466 against thymeleaf-spring5 3.0.12 show it is a backstop, not the fix.

@Controller
class WelcomeController {
    private static final Map<String, String> VIEWS = Map.of(
        "en", "user/en/welcome",
        "fr", "user/fr/welcome");

    // Vulnerable: return "user/" + lang + "/welcome";

    @GetMapping("/welcome")
    String welcome(@RequestParam(defaultValue = "en") String lang) {
        String view = VIEWS.get(lang);
        if (view == null) {
            throw new ResponseStatusException(HttpStatus.NOT_FOUND);
        }
        return view;
    }
}

Rails before 3.2.22.1, 4.1.14.1, 4.2.5.1 and 5.0.0.beta1.1 let an application that passed request data to render read arbitrary files with ../ (CVE-2016-0752). The fix restricted the lookup, but rendering a template chosen by params is still a design flaw, and Brakeman reports it as a Dynamic Render Path warning.

Express view engines have a related trap: the second argument of res.render mixes template data with engine options. GitHub Security Lab's GHSL-2021-020 (CVE-2021-32822) showed that passing req.query straight into res.render with the hbs engine let an attacker override internal options and disclose files. Pass an object you build field by field, never the request object or its query.

template.ParseFiles(filepath.Join("templates", name)) with a name from the request reads and executes any file the process can open. Parse a fixed set of templates once at startup, from an embedded file system, and select one with an allowlist of names. Nothing from the request touches the file system.

package web

import (
	"embed"
	"html/template"
	"net/http"
)

//go:embed templates/*.html
var files embed.FS

var pages = template.Must(template.ParseFS(files, "templates/*.html"))

var allowed = map[string]string{"about": "about.html", "faq": "faq.html"}

func page(w http.ResponseWriter, r *http.Request) {
	name, ok := allowed[r.URL.Query().Get("p")]
	if !ok {
		http.NotFound(w, r)
		return
	}
	if err := pages.ExecuteTemplate(w, name, nil); err != nil {
		http.Error(w, "render failed", http.StatusInternalServerError)
	}
}

Some features, such as serving documentation pages from a directory tree, really do take a path. Then decode once, resolve the path against a fixed base, and check that the result is still inside the base before loading it; resolve symlinks if the directory can contain them. In Node.js compare path.relative(base, resolved) for a leading .. or an absolute result; in Python use Path.resolve() and is_relative_to(); in Go 1.24 and later open files through os.Root, which refuses to escape its directory, or check filepath.IsLocal first. The path traversal fix cards at /fix/path-traversal/ have tested versions of this resolve-and-contain check for seven stacks, and the lab at /labs/path-traversal-python/ has you write one. Containment stops traversal, but it does not stop an attacker choosing any file inside the base, so keep executable code and secrets out of that directory.

Static analysis finds most of these bugs because the sink is a known function. CodeQL's path-injection queries (js/path-injection, py/path-injection, java/path-injection and their equivalents) report uncontrolled data used in a path expression, Semgrep has rules for dynamic require, include and render calls, and Brakeman covers Rails. Dynamic testing follows OWASP WSTG 4.2: WSTG-INPV-11 covers local and remote file inclusion as a form of code injection, and WSTG-ATHZ-01 covers directory traversal and file include. Fuzz every parameter that names a page, language, theme, template, report or plugin, not just ones called file.

Repair the code

File upload lab: Accept avatars without publishing pages

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program. CWE 4.20.
2. OWASP WSTG 4.2: Testing for Local File Inclusion (part of WSTG-INPV-11)
3. OWASP WSTG 4.2: Testing for Remote File Inclusion (part of WSTG-INPV-11)
4. PHP manual: filesystem and streams configuration options (allow_url_fopen, allow_url_include)
5. PHP manual: backward incompatible changes in PHP 8.0 (Phar metadata)
6. phpMyAdmin security announcement PMASA-2018-4 (CVE-2018-12613). 19 June 2018.
7. NVD: CVE-2016-0752, Ruby on Rails Action View directory traversal via render
8. GitHub Security Lab GHSL-2021-020: insecure template handling in hbs (CVE-2021-32822). 27 May 2021.
9. Veracode Research: Spring view manipulation vulnerability
10. Node.js documentation: ECMAScript modules, data: imports. Node.js v26.11.1.
11. OWASP ASVS 5.0.0, V5 File Handling (5.3.1, 5.3.2)
12. PortSwigger Web Security Academy: path traversal

Reference information

Tags

InjectionFile uploads and archives

SDLC phase

Development

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-5.3.1 · v5.0.0-5.3.2 · v5.0.0-1.3.2 · v5.0.0-1.3.7

CAPEC attack patterns

• CAPEC-252 at MITRE
• CAPEC-193 at MITRE

OWASP WSTG v4.2 tests

WSTG-INPV-11 · WSTG-ATHZ-01

Download this guide as Markdown

Continue exploring