Ask a Jedi: Question about CFC Security

This post is more than 2 years old.

Timothy asks:

Are there security advantages to having cfc's located outside of the webroot in the gateway/cfc folder accessed through a mapping compared to having the cfc's reside inside the specific project in the webroot?

In general the only thing you have to worry about are people invoking your CFCs remotely. CFC methods, if you do not specify an access setting, will default to public, which means they can't access them remotely. So in order for your CFC to be insecure, you would have to go out of your way to set the method to remote.

Now with that being said - I view CFCs as resources like includes and custom tags, and therefore they have no place under web root anyway. Moving them out is better (imho) for organization. You can still provide a remote facade using proxy CFCs as services.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Chris posted on 2/15/2008 at 2:20 AM

Call me a noob but if I place the cfc's in the gateway/cfc folder and IIS points my site files to c:\inetpub\wwwroot\mydomain, then what path do I put in cfinvoke?

Comment 2 by Raymond Camden posted on 2/15/2008 at 2:26 AM

If yo use a cfmapping for the site root (not web root, the site, or project root), then you can make instances of the CFC.

Comment 3 by Jason Holden posted on 2/15/2008 at 2:27 AM

How do you organize your CFC's when there are multiple sites running on the same server?

Comment 4 by Raymond Camden posted on 2/15/2008 at 2:39 AM

Not quite sure I get you. Are you saying you have multiple sites that need the same CFCs? If so, store them in some common folder, make a CF mapping (like /common), and address them there.

Comment 5 by Dan Sorensen posted on 2/15/2008 at 3:21 AM

I've created a folder outside the webroot called, "org" which is mapped in Coldfusion as "org". Then I have subfolders for a namespacing type setup that I saw Ray using. For example, "I've got "", "org.cflib" (for cflib functions), "org.esd112.service.something", "org.esd112.customtags".

So to answer Jason's question, I would create a 2nd folder under "org" (or "com" if you prefer) such as "org.siteA.something.somethingelse" and "org.siteB.stuff".

Works great. (BTW, thanks for the clarification Ray. I was wondering about the same question. :-)

Comment 6 by Jason Holden posted on 2/15/2008 at 3:41 AM

@Ray I usually put my site specific CFC's in /sys under the site root. You said they should be put outside the site root folder. I'm curious how you setup your folders outside the root. Do you put them in a directory and then use a CF mapping for each site or do you have a common place that you organize by folders (i.e. What Dan is doing)

Comment 7 by Raymond Camden posted on 2/15/2008 at 3:42 AM

I did not say that. I said put them out of web root. I only suggested out of site root for CFCs that multiple siutes use.

Comment 8 by Willy posted on 2/15/2008 at 5:38 AM

Hey Ray,

Isn't it so that if you request a CFC directly with your browser you end up with the cfcExplorer introspective CFC documentation, or am I mistaken about how that works? If so, isn't it against best-practices to expose those kinds of guts? I'm not sure I'm 100% comfortable with it. Also seems to me like another one of those theoretical problems that is not dangerous to worry much about in the real world? Thoughts?


Comment 9 by Raymond Camden posted on 2/15/2008 at 6:08 AM

You can only access CFC introspeciton docs if you know the CF Admin/RDS password, or if you have none set. That should never be true in production.

Comment 10 by Willy posted on 2/15/2008 at 6:13 AM

Oh YEAH... Ok, so that's not a problem. Thanks, Ray.

For what it's worth, we put our cfcs in an reversed-domain-name folder structure outside of our webroot, with a cf mapping directly to our edu/ folder. Now that this question has come up, I'm not completely sure WHY we do that, other than the good organizationally-specific name-spacing.


Comment 11 by Raymond Camden posted on 2/15/2008 at 6:53 AM

I believe the reverse domain thing is common in Java packages. It is convention.

Comment 12 by Tony Petruzzi posted on 2/15/2008 at 9:42 PM

I completely disagree with the logic of moving your includes, custom tags and cfcs to folder outside of the webroot. this causes more headaches then it's worth when deploying the program.

Most people don't use ant or some other automatic deployment method. Most copy the files manually and then create mappings and what not through cf administrator.

By moving these file out of the web root, now you have to remember to copy those folders as well AND remember to create a mapping for it in CF administrator. Although CF8 allows us the ability to create mappings through the cfmapping tag, you could still be restricted by the ftp process. If you only have access to your web root folder when ftpping into the site, then what good was moving the files to an outside directory for development in the first place?

A better solution (in my opinion) is to put all of your custom tag, includes and cfcs under a directory in your web root and then create an application.cfm file for that directory that does nothing but about the request.

Now your application doesn't require a mapping for it to run and your code is safe from someone trying to execute it remotely (though I don't see how you would execute an include, custom tag or cfc remotely.

Comment 13 by Raymond Camden posted on 2/15/2008 at 9:51 PM


Wow, lots of comments here.

First off - I'm not sure what FTP program you are using. I have no issues moving amongst folders. Having folders in and our of web root is no different than having sub folders under web root. If you have to navigate to upload a JS file, than what's the big deal about navigating to upload a CFC? Unless you put ALL your filers in one folder (I hope not!) than you must be moving around so that argument doesn't hold any water with me.

Secondly - if you use shared hosting and just have a web root, then the argument is moot. Yes you must stay under web root. But if you have access to a 'real' server or VPS, then you can use whatever.

Thirdly - if I can simply put my resources out of web root, I don't have to worry about adding a bunch of app.cfm files just to 'suppress' the loading of these files. In my mind, that is simpler. Why write security to block access to a resource when you can simply remove the resource from the web root.

Comment 14 by Steve Bryant posted on 2/16/2008 at 2:47 AM

For code that is not site-specific, I put it in the CustomTags folder or a subfolder thereof (CustomTags/com/sebools, for example). This makes those resources universally available without the need for a mapping (one less thing to think about).

For site-specific CFCs, the location doesn't really matter. Unless the access is "remote", then they are safe.

For site-specific custom tags, I don't think it really matters (so long as you use Application.cfm to secure them if they aren't in the web root). It isn't a bunch of app.cfm files, just one. That really isn't much trouble.

The point is that either way works, but I would hate for people who are in a situation where they don't have easy access beyond the web root to worry that they aren't secure.

Comment 15 by Raymond Camden posted on 2/16/2008 at 2:55 AM

Well technically they ARE less secure. How many people run their custom tags and includes directly to see what happens? If you can't move your files out of web root, then you must use an app.cfc/cfm 'block' as you suggested. I -do- want people to think about this.

Comment 16 by Steve Bryant posted on 2/16/2008 at 3:31 AM

Assuming that you are using Application.cfm to prevent access, how are they less secure?

Comment 17 by Raymond Camden posted on 2/16/2008 at 3:37 AM

That's what I said though - you have to write code to make it secure, whereas my way just keeps em out of web root altogether.

Comment 18 by Akira posted on 2/22/2008 at 12:55 AM

How does this work with cfgrid? I made a mapping in the administrator to a folder off the web root but when I try to bind a cfc in cfgrid it says it can't find it.

Comment 19 by Raymond Camden posted on 2/22/2008 at 3:06 AM

Because CFGRID is making an Ajax based request. If you can't hit your CFC in the browser, neither can CFGRID. YOu need to use a proxy to point to the CFCs outside of web root. A CF mapping is not the same as a web mapping.

Comment 20 by Andy Tyrone posted on 3/17/2008 at 9:56 PM

I've got clients with all types of server configurations: shared, in-house, and dedicated co-location. I use mappings for all of these configurations and keep CFCs, UDFs, custom tags, etc. outside the web root. The web root in shared hosting doesn't HAVE to be your "site root" or "account root". When I set up new shared sites I simply request a "www" folder be created in my site root directory and specify that folder as the web root. If a host won't do that for you, I'd suggest moving to one that will.

Comment 21 by Asish posted on 12/13/2011 at 6:56 PM

I have two instances of an application in same server. When i try to run a component from one instance its taking the component in the other instance ( the component in the same instance is not running ) since the directory structure is similar in both. What i have to do to get this solved? i want the corresponding component to be run from the instance it is called.. please help

Comment 22 by Raymond Camden posted on 12/14/2011 at 12:25 AM

Are both apps using the exact same name?