Is there a way to have ESAPI read the validation properties from a database table instead of using the default validation.properties file?
The short answer: No.
Check out the code here.
The relevant answer is in the documentation:
/**
* The SecurityConfiguration manages all the settings used by the ESAPI in a single place. In this reference
* implementation, resources can be put in several locations, which are searched in the following order:
* <p>
* 1) Inside a directory set with a call to SecurityConfiguration.setResourceDirectory( "C:\temp\resources" ).
* <p>
* 2) Inside the System.getProperty( "org.owasp.esapi.resources" ) directory.
* You can set this on the java command line
* as follows (for example): java -Dorg.owasp.esapi.resources="C:\temp\resources". You may have to add this
* to the batch script that starts your web server. For example, in the "catalina" script that
* starts Tomcat, you can set the JAVA_OPTS variable to the -D string above.
* <p>
* 3) Inside the System.getProperty( "user.home" ) + "/.esapi" directory
* <p>
* 4) In an ".esapi" directory on the classpath
* <p>
* Once the Configuration is initialized with a resource directory, you can edit it to set things like master
* keys and passwords, logging locations, error thresholds, and allowed file extensions.
* <p>
* WARNING: Do not forget to update ESAPI.properties to change the master key and other security critical settings.
*
* @author Mike Fauzy ([email protected])
* @author Jim Manico ([email protected])
* @author Jeff Williams (jeff.williams .at. aspectsecurity.com) <a
* href="http://www.aspectsecurity.com">Aspect Security</a>
*/
If you want that kind of behavior you'll have to manually alter esapi source and (hopefully) do so in a way that can ignore specific database implementations.
Also consider that for a security library, its a little less secure to manage many of these things in a database. The recommendation from OWASP is to manually compile this library yourself with the properties files in the src/main/resources directory. That way, for an external actor to be able to alter your configuration, they would have to have a unix account on your machine, assuming you're keeping to Java standards. (WEB-INF/ is naturally protected.) If you put this in the database, then in theory your security configurations are open to SQL Injection threats... why risk it?
Having those files in the library itself puts them directly on the class path which makes it much more difficult to alter. If you DO decide to implement this in a database, be extremely careful about TOCTOU errors (Time Of Check to Time Of Use).