Follow the steps below.
Step 1: Create the New Script Directory and copy the existing cf_scripts content to the new Script Directory.
Create a new Scripts Directory (C:/cf_scripts) and copy the existing cf_scripts content ({cf_root}/cfusion/wwwroot/cf_scripts) to the new Scripts Directory.

Step 2: Edit server.xml
Take a backup of the existing server.xml file in the ({cf_root}/cfusion/runtime/conf) directory. This ensures you can revert to the original configuration if needed.
Open the server.xml file in a text editor and add the following configuration:
</Context>
<Context path=”” docBase=”C:/ColdFusion2025/cfusion/wwwroot” WorkDir=”C:/ColdFusion2025/cfusion/runtime/conf/Catalina/localhost/tmp”>
<Resources>
<PreResources base=”C:/cf_scripts/scripts” className=”org.apache.catalina.webresources.DirResourceSet” webAppMount=”/cfscripts-10/scripts”/>
</Resources>
</Context>

- Use C:/cf_scripts/scripts as a physical directory
- Mount it virtually at /cfscripts-10/scripts
Step 3: Update the cf_scripts path in the Administrator.
- Take a backup of neo-runtime.xml located under cfusion/lib.
- Update the new cf_scripts path in ColdFusion Administrator → Server Settings → Settings → Default ScriptSrc Directory, and submit the changes.

Note: The ScriptSrc directory path can also be updated in the neo-runtime.xml file on the backend.
Step 4: Restart the ColdFusion server and verify that you can log in to the ColdFusion Administrator.
Note: Any changes made to server.xml or neo-runtime.xml require a ColdFusion restart for the changes to take effect.
Follow the steps below.
Step 1: Create the New Script Directory and copy the existing cf_scripts content to the new Script Directory.
Create a new Scripts Directory (C:/cf_scripts) and copy the existing cf_scripts content ({cf_root}/cfusion/wwwroot/cf_scripts) to the new Scripts Directory.

Step 2: Edit server.xml
Take a backup of the existing server.xml file in the ({cf_root}/cfusion/runtime/conf) directory. This ensures you can revert to the original configuration if needed.
Open the server.xml file in a text editor and add the following configuration:
</Context>
<Context path=”” docBase=”C:/ColdFusion2025/cfusion/wwwroot” WorkDir=”C:/ColdFusion2025/cfusion/runtime/conf/Catalina/localhost/tmp”>
<Resources>
<PreResources base=”C:/cf_scripts/scripts” className=”org.apache.catalina.webresources.DirResourceSet” webAppMount=”/cfscripts-10/scripts”/>
</Resources>
</Context>

- Use C:/cf_scripts/scripts as a physical directory
- Mount it virtually at /cfscripts-10/scripts
Step 3: Update the cf_scripts path in the Administrator.
- Take a backup of neo-runtime.xml located under cfusion/lib.
- Update the new cf_scripts path in ColdFusion Administrator → Server Settings → Settings → Default ScriptSrc Directory, and submit the changes.

Note: The ScriptSrc directory path can also be updated in the neo-runtime.xml file on the backend.
Step 4: Restart the ColdFusion server and verify that you can log in to the ColdFusion Administrator.
Note: Any changes made to server.xml or neo-runtime.xml require a ColdFusion restart for the changes to take effect.
- Most Recent
- Most Relevant
Folks (Adobe and readers), there’s so much wrong here. I started a comment last week the day this was posted, and sadly it was lost before I submitted it. Let me try again.
- Step 1 is wrong, at least step 1 as written originally here and still as of today March 4, 2026: we should NEVER copy the cf_scripts/scripts folder to a new location and point CF to that. There’s not only no benefit to it, there is grave detriment: if you later run a CF update, that may (often does) write new or changed files. It will put those changes in the ORIGINAL cf_scripts/scripts–not this new one. And now you’re relying on old, unupdated files.
- As important, if one is using an external web server (IIS or Apache) then it’s vital to complete another step after step 3 above (changing the default script src in the CF Admin). Here’s the point: assuming you have already run the CF wsconfig tool, it would have created a virtual directory (in IIS) or an alias (in Apache) using that former /cf_scripts/scripts name. After the change in step 3, you must change any such IIS virtual directory or Apache alias use that new name.
- Otherwise, any requests to CF pages that RELY on this script src value will get a 404. And that would often be a silent failure in most browsers, with some javascript not doing its job.
- (To be clear, any subsequent running of the CF wsconfig tool WILL put in that new value.)
- Also, that virtual directory would have to name the folder where the files should be found, and again that should be the existing wwwroot/cf_scripts/scripts folder. The whole point of it being a virtual directory is that the web server is being told where to find it, but the change in step 3 tells CF to create HTML (for some CF tags) that would name the path as indicated in step 3.
- Otherwise, any requests to CF pages that RELY on this script src value will get a 404. And that would often be a silent failure in most browsers, with some javascript not doing its job.
- Beware about step 2 (editing the server.xml) that you do NOT just copy/paste the XML elements or even the quoted strings within some. In this blog post they are FORMATTED double quotes and if you use them in your server.xml CF will not start. You need to change them to unformatted (” not ”). Adobe should of course change this post so that that XML is in a “code” block, which would help.
- And again, I would argue that that step 1 should NOT have you pointing to a new folder from which you copied the cf_scripts/scripts content. Instead it should point to that existing one (in the preresources “base” value above.)
- And again, I would argue that that step 1 should NOT have you pointing to a new folder from which you copied the cf_scripts/scripts content. Instead it should point to that existing one (in the preresources “base” value above.)
- As helpful as is this whole change (of the default script src–though it’s kind of “security by obscurity”), note that in some cases I have found that in doing it, that can lead to a failure (when applying CF updates) where you will see that CF’s ajax package may fail to load during CF startup. I’ve never gotten around to documenting that better. Just beware.
- It’s kind of curious that this post proposes using as the new name /cfscripts-10/scripts. That makes me think this was something that existed as steps somewhere else since 2012 (when cf10 came out, and was the first CF version running on Tomcat), where perhaps Aruna found and resurrected the content. I’m not suggeting that value is wrong, just that it’s perhaps telling.
Some good news and additional info to help readers
Finallly I’ll acknowledge something helpful about about this post is that it’s nice to see its discussion in step 2: the need to edit the server.xml, which affects any calls into the CF built-in web server–which the CF Admin uses. Many are unaware that if you do step 3 here but don’t do step 2, then some parts of the CF Admin (or any CF requests run via the CF built-in web server) that rely on this script src location will fail (again either silently or prominently).
I know I’ve left out some detail above which some readers may need. Again, I want to get this out there before too many people might rely on it. Indeed, today a post was made on the FusionReactor blog that parroted alot of this info (even using the curious /cfscripts-10/scripts choice made here). There is no comment feature there, so I have added this here and mentioned on their tweet (about their post) that there are these problems/concerns, here in this original post.
And certainly If anyone reading this has any argument or assertion that I am somehow mistaken, I welcome the discussion. I just am passionate about this problem because I’ve helped people solve problems with this whole default script src matter for years (as have some others in the community).
Indeed, Pete Freitag (who Adobe has had write the CF Lockdown Guides for over a decade) had a post on that imporant need to change the server.xml). He also has a post with other info on the matter of the default script src.
But note the in neither does he propose that one MOVE or COPY what’s IN that cf_scripts/scripts folder to a new location. That’s the most heineous concern I have about this post (and it’s currently its STEP 1, as I write in early March 2026). Then there’s the need to deal with the virtual directory in IIS or alias in Apache–which Pete covers in his second post above.
Hope all this is helpful to some readers.
Replying to @Charlie Arehart: Yes, I totally agree with Charlie here! That approach can lead to all sorts of problems.





