Potential gotcha with searchImplicitScopes and cfparam

The recent ColdFusion security hotfix that changed searchImplicitScopes defaults has been keeping developers busy fixing unscoped variables. This can be pretty tedious, and not all variables technically need a scope (such as a query variable inside a cfoutput) to function properly. One interesting case, that I bet is causing some bugs looks something like this:

<cfparam name="page" default="1" type="integer">
<cfoutput>Top Stores Page #page#</cfoutput>

How the code works when searchImplicitScopes = true

When searchImplicitScopes = true (this was the default behavior in ColdFusion up until the recent change), ColdFusion would, well, search the implicit scopes - url, form, etc.

So a request for news.cfm?page=2 would output Top Stories Page 2. A request for news.cfm would output Top Stores Page 1, and in this case the cfparam tag would assign variables.page=1.

How the code works when searchImplicitScopes = false

With searchImplicitScopes = false no scope searching takes place for an unscoped variable.

Now a request for news.cfm?page=2 would output Top Stories Page 1. No matter what page number you pass into the url query string, this code would always think you are on page 1.

With search implicit scopes turned off, cfparam is only going to check the variables scope, and if it is not already defined, it will assign variables.page=1.

As you can see, this code example did not return an error, and though I haven't tested this, I assume that it would not be logged to the unscoped.log file either. That makes these a very subtle bug, keep an eye out for this one!

As you may know, back in October when this change first arose I added an unscoped variable scanner to Fixinator. I did double check the above code example, and Fixinator will infact flag this, so if you are looking for a way to locate this type of bug in your application, give Fixinator a try.