Error with ESAPI functions / could not be loaded by any means

On our server we are getting errors when using ESAPI functions such as encodeforHTML (randomly, more or less once a week, restarting the server helps as a workaround)

The error message is: java.lang.reflect.InvocationTargetException SecurityConfiguration class (org.owasp.esapi.reference.DefaultSecurityConfiguration) CTOR threw exception.

I attached a screenshot from the stack trace which indicates that there is a problem loading the standard Lucee file

org.owasp.esapi.errors.ConfigurationException: could not be loaded by any means. 

Fail. at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration( at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>( at
 org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>( at
 org.owasp.esapi.reference.DefaultSecurityConfiguration.getInstance( ... 58 more Caused by: java.lang.IllegalArgumentException: Failed to load as a classloader resource. at 
org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurationFromClasspath( at 
org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration( ... 61 more

So how can I make sure that is always loaded?

Lucee on Ubuntu 18.04 LTS
ESAPI Extension (also tried, no difference)

Many thanks

I was tried encodeforhtml(),ESAPIEncode() & ESAPIDecode() in lucee with the ESAPI Extension Both of them works & doesn’t throw any error. I made this check in Windows 10 & my java version is 1.8.0_212 (Oracle Corporation) 64bit. Once i got a issue I’ll post it here.

As I wrote, this happens only from time to time, more or less once a week, my java version is 1.8.0_202 (AdoptOpenJdk) 64bit btw. Thanks for keeping an eye on this :slight_smile:

We have that on our servers… I believe it’s because it’s an extension now. In our case, we have a CFC that on init runs

CreateObject("java", "org.owasp.esapi.ESAPI").encoder()

If this runs before an encodeForX() runs, then we get these errors.

Our fix at the moment is that the healthcheck that runs to set the server up, specifically calls encodeForHTML() to output something; this then allows our CFC to init and for other calls to encodeForHTML() to work.

Thanks for your reply, which might be helpful because we had some old code similar to yours in some CFCs which maybe got called once a week…

<cfset esapi = CreateObject("java", "org.owasp.esapi.ESAPI")>	

Luckily we are able to get rid of this code and will see what happens.

Please file a bug!


1 Like

Had the same issue with fresh install of Windows Server 2019, Lucee, ESAPI

To fix I copied & from a working Coldfusion install into “\lucee\tomcat\lib”

Hi there,

could you add a comment to the above bug? I have just added your affected versions

Did you use the Lucee installer? are you using IIS?

Yes, used the Lucee Windows Installer & Running IIS 10

the problem is that extensions are lazy loaded

are you calling

CreateObject("java", "org.owasp.esapi.ESAPI");

the workaround is just to call encodeForHtml("") first




CreateObject(“java”, “org.owasp.esapi.ESAPI”)

didn’t resolve the issue in my case.

I’ve now added a comment to the bug from above as well. Hope this helps.

after a restart?

lol, after a many restarts, scratching my head, scouring the internet, Downgrading the ESAPI extension, re-upping the extension.

Determined that if the error stated that it couldn’t read the property files I’d check to see how ACF uses them and where they’re stored and copied them over. Reverted my code to the same state that works in ACF restarted Tomcat and voila success; working assess to the ESAPI encoder methods.

That worked for me, but damn, why is this bug still marked as New and why is it still not fixed 3 years after it was reported?

Just because it hasn’t be resolved yet, doesn’t mean we haven’t been trying to. It’s a difficult bug