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 ESAPI.properties file
org.owasp.esapi.errors.ConfigurationException: ESAPI.properties could not be loaded by any means.
Fail. at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:443) at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(DefaultSecurityConfiguration.java:226) at
org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(DefaultSecurityConfiguration.java:252) at
org.owasp.esapi.reference.DefaultSecurityConfiguration.getInstance(DefaultSecurityConfiguration.java:67) ... 58 more Caused by: java.lang.IllegalArgumentException: Failed to load ESAPI.properties as a classloader resource. at
org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurationFromClasspath(DefaultSecurityConfiguration.java:682) at
org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:440) ... 61 more
So how can I make sure that ESAPI.properties is always loaded?
Lucee 5.3.1.103 on Ubuntu 18.04 LTS
ESAPI Extension 2.1.0.16 (also tried 2.1.0.17-SNAPSHOT, no difference)
Many thanks
I was tried encodeforhtml(),ESAPIEncode() & ESAPIDecode() in lucee 5.3.1.103 with the ESAPI Extension 2.1.0.16. 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 
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.
Had the same issue with fresh install of Windows Server 2019, Lucee 5.3.6.61, ESAPI 2.2.0.0-SNAPSHOT.
To fix I copied ESAPI.properties & validation.properties 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
Calling:
encodeForHtml(“”)
Before:
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.
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
1 Like
@Zackster I have this issue on Lucee 6.1.1.118 - will more stack traces help?
All Lucee Extensions are current, only Lucee is behind.
Platform is Tomcat 9 on Debian 12 with latest updates.
Lucee-Bug-LDEV-2293-Java-Stack.html (68.8 KB)
Lucee-Bug-LDEV-2293-CFDUMP.html (69.1 KB)
Please try the latest 6.2.1 stable release, we’ve done a lot of work since 6.1.1 and my time is limited
My application has three entry points with one found to reproduce the issue consistently as the first request after Tomcat restart for a few hours after which the issue no longer replicated. IMO this suggests a startup race condition.
Due to recent Lucee release regression history, management has prohibited Lucee version upgrades without full regression test for which we have no budget so 6.2 is not an option at this time.
IMO best use of limited time is forward provided stack traces to developer with most experience with relevant code to perform the best technical triage possible without committing substantial time unless such triage uncovers a time certain remedy.
We put a lot of work in to making the 6.2 release really, really solid and the feedback on the 6.2 release has been really positive.
I’m sorry about your past experiences with older releases.
As we won’t be making another 6.1 release, your only path forward is to upgrade and if the problem still occurs we will address it.
IMHO, it’s my mostly time I spend here on Lucee, so it’s my time and my decisions about what I work on, donations are always welcome
But the good news is, if you’d checked jira, as I just did, you’ll see that we have indeed addressed this issue in 6.2.0.294, time to regression test and upgrade.
https://luceeserver.atlassian.net/browse/LDEV-5217
1 Like
