Reserved words in ColdFusion

Last updated on Dec 19, 2025

Reserved words and reserved variable names in ColdFusion

ColdFusion reserves certain words and variable names for the language itself and for built‑in features (scopes, tags, functions, and internal data structures). Using these words for your own variables, function names, or component names can:

Cause your code to fail to compile.
Change how a variable is resolved at runtime (for example, a function argument vs. an implicit scope).

Categories of reserved words

ColdFusion reserves words in four broad categories:

Language keywords

Language keywords have syntactic meaning in cfscript or tags.

Examples include:

if, else, for, while, switch, case, default, break, continue
try, catch, finally, return, throw
var, local, new, extends, implements, interface, package
public, private, static, final, abstract
function, component

These words cannot be safely used as identifiers in contexts where the parser expects a keyword. Some words are reserved only in specific contexts (for example, first and last within Query‑of‑Queries).

Tag names and built‑in tag attributes

Names for CFML tags are reserved.

For example:

cfif, cfelse, cfloop, cfquery, cfoutput, cfinclude
cfcomponent, cffunction, cfargument
cfdocument, cfhttp, cfmail, cfthread, and all other documented ColdFusion tags.

You can use such a name as a plain string or a variable in other contexts, but you must not use a tag name in any position where a tag is expected.

Built‑in functions (BIFs)

Names of ColdFusion built‑in functions are reserved as function identifiers in CFScript and in function‑call contexts.

Examples include:

arrayLen, structKeyList, duplicate, serializeJSON, deserializeJSON
isNull, encrypt, decrypt, hash, listToArray
queryExecute, getPageContext, createObject, and many others.

You can still have a variable whose value is a reference to a built‑in function (for example, for use as a callback), but you should not define your own function or CFC method with the same name as a built‑in function. This can cause unexpected behavior and is increasingly rejected or warned about in recent releases.

Reserved variable and scope names

Certain identifiers are used as scopes or internal structures. These names are reserved as top‑level variable names:

Standard implicit scopes (for example, Server, Application, Session, Local, Arguments).
Internal / feature scopes created by tags and frameworks (for example, cfdocument, cfcatch, cfhttp, file, error, pdf).
Names used as built‑in “data structures” that expose system or request state.

This category is where recent security changes could cause previously working code to break if it reused those names.

Reserved scope names

ColdFusion defines a set of implicit scopes. Many of them are visible both in templates and in CFC methods, and are searched when you refer to a variable without a scope prefix.

These scope names are reserved and must not be used as your own variable or argument names at the top level:

Scope name	Description
Application	Application-wide variables
Session	Per-session data
Server	Server-wide data
Client	Client-specific persistent variables
Request	Per-request shared data
CGI	CGI-environment variables
URL	Query-string parameters (user-controlled)
Form	Form POST parameters (user-controlled)
Cookie	Cookie values (user-controlled)
Variables	Default template scope for unscoped variables
Local	Function‑local variables (functions, UDFs, CFC methods)
Arguments	Function/method arguments
Thread	Data in a <cfthread> thread
ThreadLocal	Per‑thread local scope inside threads
File / Cffile	Data related to file uploads and <cffile> operations
cfdocument	Scope created by <cfdocument> to expose pagination variables

ColdFusion also uses additional internal scopes such as Error, File, Pdf, and others to support engine features (error handling, file uploads, PDF processing, and so on). These may not all be documented individually, but they should be treated as reserved identifiers when used as un-scoped or top‑level names.

Important

Because of scope‑injection fixes, names like server, file, error, pdf, etc. may now behave differently from older releases if you used them as your own argument or local variable names without explicit scoping.

Reserved built‑in data structures and internal scopes

Several tags and features create implicit scopes or structures that appear as variables during the lifetime of the tag. These names are reserved within those contexts, and you should avoid re‑using them as generic variables:

Context/tag	Reserved scope/structure	Notes
<cfdocument>	cfdocument	Pagination and document variables.
<cfcatch>	cfcatch	Error structure (message, detail, etc.).
<cfhttp>	cfhttp	HTTP response data (headers, body, status).
<cffile>	file	Server file path, name, status, etc.
Exception handling and logging	error	Engine‑level error information in some contexts.
PDF tags (such as <cfpdf>)	pdf, cfpdf	Structures related to PDF operations.

Historically, documentation referred to these collectively as “built‑in data structures, such as Error or File”. Going forward, you should treat all names that correspond to these internal structures as reserved for:

scoped access (for example, file.serverFile, cfdocument.currentpagenumber), and
engine behavior.

Do not use them for your own argument names, local variables, or un-scoped variables.

Behavior changes in recent releases

Recent ColdFusion updates introduced behavior changes related to implicit scopes, scope search, and scope-injection protection. These changes are security‑driven and can expose code that previously relied on ambiguous or unsafe scoping.

Implicit scope search and searchimplicitscopes

Historically, when you used a variable name without a scope prefix, ColdFusion would search multiple scopes in order (for example, Local → Arguments → Variables → CGI → URL → Form → Cookie → Client) until it found a match.

To improve performance and security, recent updates:

Introduced searchimplicitscopes as an application setting and JVM flag:
- this.searchimplicitscopes in Application.cfc, and
- -Dcoldfusion.searchimplicitscopes as a JVM argument.
Changed the default so that searchimplicitscopes is false in newer updates.
Limited or removed automatic searching of unscoped variables across all implicit scopes.

As a result:

Un-scoped variables are far less likely to silently resolve to user‑controlled scopes (URL, Form, Cookie).
Code that relied on implicit resolution from URL/FORM/COOKIE/CGI without scope prefixes can now throw “variable is undefined” errors.

Scope‑injection vulnerability fix (internal scopes vs. user variables)

A security fix addressing scope injection changed how ColdFusion resolves variable names that can collide between:

user‑controlled scopes (such as URL, FORM, COOKIE), and
non user‑controlled / internal scopes (such as Server, internal File, Error, Pdf, and others).

ColdFusion now first checks the built-in/internal scope for a matching variable name. If the variable is not found in the built-in scope, it then checks the argument scope.

Previously, argument or local variables whose names matched internal scopes (for example, file, error, server, pdf) could be accidentally overridden by user input or could override internal behavior, depending on the resolution order.

.After the fix:

on user‑controlled scopes and internal scopes are protected and have correct precedence over user‑supplied data (argument/url/form/cookie scope).
ColdFusion still resolves ambiguous variable names, but the resolution order has changed in recent releases.
The engine now first checks the built-in or internal scope for a matching variable name.
If the variable is not found in the built-in scope, ColdFusion then checks the argument scope.
This change reduces the risk of unsafe scope injection and prevents user-defined arguments from overriding internal behavior.
In some cases, ColdFusion will treat such names as references to the protected (built-in) scope, or will throw an error if a conflict exists, rather than silently using a conflicting variable.
Legacy code that relied on the previous resolution order (argument scope first) may behave differently or encounter errors after this update.

This means that code which:

defined by argument name server or file, or
used unscoped variables named error, pdf, and so on,

may now behave differently, and in many cases may behave unexpectedly with:

Variable {xxx} is undefined, or
unexpected behavior compared to older releases.

The preference order will be updated to check the server scope first, and if it isn't found there, then check the argument scope.

Best practices

To avoid bugs and future breaking changes, and to remediate issues in existing code, follow these guidelines:

Do not use reserved scope names for your own variables

Avoid using any of the following as variable or argument names, especially unscoped or at the top level:

server, application, session, client, request
variables, local, arguments
url, form, cookie, cgi, file, cffile
cfdocument, cfcatch, cfhttp, cfpdf, pdf, error

Prefer alternative names such as:

serverConfig, sessionInfo, clientData
fileInfo, uploadFile, errorInfo, pdfResult

Always prefix variables with their scope

Use explicit scoping for all non‑local references:

// Recommended 
variables.userName = "alice"; 
request.context.userId = 123; 
session.userProfile = profile; 
application.config.timeout = createTimeSpan(0, 0, 30, 0); 
 
// Not recommended (relies on implicit scope search) 
userName = "alice";       // ambiguous 
context.userId = 123;     // "context" is not a scope

This improves both performance and security and is strongly recommended in general ColdFusion variable guidelines.

Search your codebase for risky names

Before or after applying updates that include scope‑injection fixes and searchimplicitscopes changes:

Search your code for these identifiers used as arguments or unscoped variables:
- server, application, session, client, request
- variables, local, arguments
- file, error, pdf, cfdocument, cfcatch, cfhttp, cfpdf
Rename or refactor them to avoid collisions with internal scopes and structures.

Use searchimplicitscopes only as a temporary workaround

If your application encounters any Variable {xxx} is undefined or UndefinedElementException errors immediately after an update:

You can temporarily:

Set this.searchimplicitscopes = true; in Application.cfc, or
Add -Dcoldfusion.searchimplicitscopes=true to the JVM arguments.

This can restore legacy unscoped variable resolution while you refactor your code. However:

This flag and setting re‑enable behavior that is both slower and less secure.
The JVM flag is planned for removal in a future major release.
Treat this only as a short‑term migration aid, not as a permanent configuration.

Get help faster and easier

New user?