Web applications face a wide range of security risks. Security Analyzer flags the following categories during a scan:

Manual review for these issues is slow and error-prone. Security Analyzer automates the detection so you can focus on fixing the code.

The following table shows who uses Security Analyzer and how:

Confirm each item before you run a scan:

Install and configure the extension once before you run any scan:

The following table summarizes the actions available from the Security Analyzer submenu:

After a scan completes, work through each finding:

Run a clean scan when you want previously ignored findings to surface again:

Export results to share with auditors or to attach to a build pipeline:

The Security Analyzer view in the extension uses a top-to-bottom layout, with a header bar, summary cards, charts, a filter bar, and an issues table.

The header bar appears at the top of the view. It shows the project name, the scan timestamp, and the Export action.

A row of summary cards shows scan totals at a glance. Select any card to apply it as a filter on the issues table:

Donut charts summarize the issue mix by Status, Issue type, Severity level, and Attack type. Each chart segment is selectable and applies the matching filter to the issues table.

The filter bar narrows the issues table by File name, Attack name, Severity, and Type. Filters combine, and Clear filters resets them.

The issues table lists every finding the scan returned. Each row shows the file, line, attack name, severity, and status. Selecting a row opens the inline detail panel with the problem statement and the suggested fix. Selecting the row again opens the file in the editor at the offending line.

Security Analyzer assigns each finding one of three severity levels:

Use these built-in functions to sanitize user input for the matching output context:

The complete, authoritative rule inventory lives in codeanalyzerrules.json on the server. The lists below group those rules by category for orientation.

The following table lists every rule that ships in ColdFusion 2025.0.08, with the rule name as it appears in codeanalyzerrules.json and its default severity. To enable or disable a rule, set "enabled": true or "enabled": false on the matching entry in the rules file.

The vulnerable pattern passes user input directly into a MongoDB query:

The safe pattern validates the input and passes it as a typed string:

The vulnerable pattern passes user input to cfexecute:

The safe pattern resolves the command from a server-side allowlist, validates any arguments against a strict regular expression, and runs the command with a timeout:

The vulnerable pattern flows user input directly into an LDAP filter:

The safe pattern encodes the input with encodeForLDAP():

The vulnerable pattern concatenates user input into an XPath expression:

The safe pattern encodes the input with encodeForXPath():

The vulnerable pattern lets user input drive dynamic code execution or a cfinclude path:

The safe pattern validates against an allowlist and uses fixed paths. Replace evaluate() with a switch over expected values whenever possible. The same allowlist rule applies to Java-side script evaluation through ScriptEngine.eval():

The vulnerable pattern uses weak algorithms to hash sensitive data:

The safe pattern uses SHA-256 for general integrity hashing, and a slow, salted, work-factored key derivation function for passwords. The variable passwordHash holds the PBKDF2 output and is the value stored in the database:

The vulnerable pattern below uses a hardcoded key to encrypt data and stores a plaintext password in the database:

The safe pattern reads the encryption key from the environment, hashes the password with PBKDF2 (stored in passwordHash), and uses parameterized queries:

The vulnerable pattern places user input in event handlers or in script content:

The safe pattern avoids user input in event handlers and encodes for the correct context elsewhere:

The vulnerable pattern lets user input drive file paths, directory listings, or cfinclude:

The safe pattern resolves the canonical path before any comparison. A naive startsWith check on the raw input does not stop traversal, because the path /var/www/uploads/../../etc/passwd still starts with /var/www/uploads/. Verify the canonical path falls inside the canonical base directory and apply a filename allowlist:

The vulnerable pattern illustrates two anti-patterns to avoid. In the first, the role is read from a form field, so the caller can claim any role. In the second, a session identifier is taken from the URL parameter, which is a session-fixation vector. Note that sessionInvalidate() does not accept a session identifier argument; calling it this way reflects an incorrect assumption about the API signature:

The safe pattern uses cflogin and cfloginuser to authenticate the user, stores roles in server-side session state, and rotates or invalidates sessions through the official ColdFusion APIs. Replace the placeholder calls with your application's credential-verification query and role-lookup query:

In the vulnerable pattern, a function-local intent declared with var is referenced unscoped. The reference resolves to whichever scope holds a matching name first, which may be form, url, or another caller-controlled scope:

The safe pattern uses the local scope on both the declaration and the reference, so the lookup cannot fall through to a caller-controlled scope:

For large projects, Security Analyzer needs more time. Increase the RDS timeout that the extension uses to reach the analyzer:

Security Analyzer rules and per-rule enablement live in codeanalyzerrules.json under your ColdFusion install directory:

Edit the rules file when you want to turn an individual rule on or off:

A rule entry looks like this:

If the extension cannot reach the server, complete the following checks:

The scan flows through the following stages:

Adopt these habits to get the most value from Security Analyzer:

The following table lists common scan problems and the action that resolves each one:

A standalone command-line Security Analyzer tool is on the roadmap for a future release. The planned tool supports continuous integration pipelines, scanning without an integrated development environment, multiple output formats including SARIF, and configurable rules and severity thresholds.

The following examples show planned command-line use:

The following table shows planned configuration options:

Until the command-line tool ships, run scripted scans against the RDS endpoint that the extension uses. The scripted approach requires the Developer profile, valid RDS credentials, and network access to the server.

The exported HTML or PDF report is a multi-section document with the following parts:

JSON and CSV exports contain the findings list data only, suitable for downstream tools.