Include resolution in Pug 3.x remains unrestricted relative to template directory

In Pug 3.x, the default behavior where include and extends resolve relative to the current template's directory is intentional and stable. This design choice maintains full backward compatibility with Pug 2.x and provides flexibility for complex project structures that may not fit a strictly flat directory hierarchy.

The Resolution Mechanism

By default, Pug does not enforce a 'sandbox' or a restricted root boundary. If a template is located in /public/views/, it can technically use include ../../private/config.pug to access files outside the public-facing folder, provided the Node.js process has the necessary file-system read permissions.

The Role of basedir

The basedir option is the primary mechanism for changing resolution semantics. When basedir is defined in the render options:

• Relative paths are no longer resolved relative to the current file's location.
• Paths are instead resolved relative to the basedir path.
• This effectively creates a 'virtual root', making it easier to manage shared components without deep relative-pathing.

Preventing Unauthorized File Access

Because Pug itself does not provide a configuration-level boundary to prevent reaching outside a directory, security must be handled at the application or infrastructure level. To prevent a publicly-served template from including private files, consider these strategies:

1. Directory Isolation: Place all templates in a directory that is not served by your static file server (e.g., a /views folder outside of /public).
2. Explicit basedir: Set a strict basedir and ensure all includes start from that known root.
3. Input Validation: If your application allows user-influenced template names, strictly sanitize the input to prevent directory traversal (../) before passing it to the Pug engine.

Is your application passing user-provided strings directly into the render function? If so, manual path sanitization is your only definitive defense.