Archived Forum Post

Index of archived forum posts


Chilkat.FileAccess not marked as "safe for scripting"?

Jul 23 '12 at 09:56

Loving your product, but I’m having difficulty accessing the ActiveX components from a plain .js script. Chilkat.FileAccess works fine when written within an HTA for example but not when run as a standalone script. Windows Scripting.FileSystemObject runs from a standalone script just fine, but it’s some 20x slower than your component. All my research on the matter indicates that the cause of the problem is that the ActiveX object is marked “Not Safe for Scripting”. Would you be willing to modify the component so that I may use it in this manner?


This is a good question. A good article I would recommend about Script and IE Security is located here:

This part of the article summarizes the issue:

An object which claims to support the "safe for untrusted callers" bit is saying "it does not matter what methods you call on me, I cannot possibly do anything harmful." Essentially the object is saying that its capabilities are so weak that no matter how hostile the caller, nothing bad will happen. The "Scripting.Dictionary" object is an example of such an object -- no matter what, it cannot do anything more than store a list of (key, value) pairs. It cannot format your hard disk or send your private data to

An object which supports this bit is also known as a "safe for scripting" object -- it may be safely called from an untrusted script.

It wouldn't be right to mark Chilkat.FileAccess as "safe for scripting" because the intended purpose of the ActiveX is to read/write files, delete files, create/delete directories, etc. All of these things can obviously be harmful if used from an untrusted script. However, if used from a trusted script, or from a trusted Windows application (such as a VB6 app, Delphi app, etc.), then there is no issue.

Microsoft's Scripting.FileSystemObject should also be "not safe for scripting" for exactly the same reason. See

The answer to your question is that it's not possible to mark the ActiveX as "safe for scripting". My suggestion for a workaround is to determine how to make your .js script a trusted script, and if trusted, then according to what the referenced article implies, you should be able to use an "unsafe" ActiveX from a trusted script.