Chris Peters: Web Developer

Securing your CFCs, custom tags, includes, and config files

Filed under: Programming — Chris Peters, April 9, 2005

I recommend that all ColdFusion developers read the Macromedia Web Technology Group’s (WTG) ColdFusion MX Coding Guidelines document to see how the company uses its own technology for its Web site. It certainly has guided me into developing my own style.

One interesting section I saw in the document was a section about where a Web site’s business logic should sit. The group decided that source files for ColdFusion Components (CFCs), custom tags, includes, and configurations should sit in directories outside of the Web root. This gives all applications on the server greater scalability and tighter security. Without the files being in a directory under the Web root, no one can access them from a Web browser (which often causes a CF error to be thrown, potentially exposing sensitive information). Putting business logic and includes outside of the Web root makes it that much more difficult for malicious coders to compromise a site’s security.

Macromedia’s WTG keep their extensibility files in a folder called extensions. Under extensions are folders called components, customtags, and includes. In the same folder as extensions is a folder called config. The image below best illustrates this setup:

A hierarchical display of how ColdFusion extensions should be placed in a Web server.

In the ColdFusion Administrator, all that needs to be set up are mappings that point to the components, includes, and config folders. Also, a custom tag path (and optionally another mapping for use with cfmodule) should be made for the path to the customtags folder. That way ColdFusion scripts can access the files, but no other transaction can.

config is worth further discussion because the WTG recommends putting all application configurations in a file outside the Web root and then including it into the application’s Application.cfm. That way an application could be copied into multiple locations (on the server or different servers), each application pulling in its own settings from its own dedicated config file, without having to modify Application.cfm. This makes deploying changes to mulitple applications much more simple, and it makes it possible to distribute compiled .cfms with only the source of the config file being readable. (The contents of config file usually only set some variables to be used by the application in the request scope).

Special thought should go into naming the components mapping because that mapping name will be used in CreateObject(), cfobject, etc. Using Java-style conventions, the mapping name should make sense in a package-like convention. I sometimes name my components mapping “business” because the business logic is located there. Then you can call Java-like package paths in CreateObject() like so:

<cfset application.cart = CreateObject(’component’, ‘business.Cart.Gateway’)>

What if I am subscribed to shared hosting and can’t create mappings pointing to files outside of the Web root?

I recommend creating a folder in the Web root called extensions and putting in a request to the hosting company to configure the folder so that it can’t be served. This sets the files so that they can only be accessed by scripts on the server.

Caveats of this methodology

Although changing large sites to this architecture can be painful, I’ve found it to be a worthwhile task to complete in order to accomplish easier application scalability.

Another pain created by this method is that you have to create a whole other Dreamweaver Web site. That means you must to switch between the sites every time you need to make a change to an application’s business logic. Also, it is annoying for a developer who is working on an application alone; switching between sites to work on business and presentation logic does waste some time. But most Web ventures will grow enough in time to where such a separation will be beneficial. (It would enforce that Developer A should only be working on the design and caller files while Developer B should only be working on the business logic in CFCs, includes, and custom tags).

Again, I recommend reading the Coding Guidelines document on Macromedia’s Web site for more interesting pieces of advice. They’ve been kind enough to allow the outside world read their recommendations, so we should at least be considering their advice.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment