It is important that you do this, and let me explain why.
Fundamentally, the APEX "engine" is really nothing more than a big PL/SQL program running inside the Oracle Database. When a browser makes a request for a page in an APEX application, that request is mapped to a PL/SQL procedure which is running inside the database. If you examine an APEX URL in your browser, you may see something like 'f?p=...', and this is invoking a PL/SQL procedure in the database named 'F' with a parameter named 'P'.
There are a number of procedures in the APEX engine which are intended to be invoked from a URL. But there may be other procedures in your database, possibly owned by users other than the Application Express user, which are not intended to be called from a URL. In some cases, these other procedures could leak information or introduce some other class of security issue. There should be a simple list of procedures which are permitted to be invoked from a URL, and all others should be blocked. This is known as a "whitelist", and fortunately, there is a native facility in APEX which defines this whitelist. You just need to tell ORDS about this whitelist.
When you configure ORDS with the following entry in the configuration file:
You are instructing ORDS to validate the PL/SQL procedure requested in the URL using the PL/SQL function wwv_flow_epg_include_modules.authorize. This whitelist will contain all of the necessary entry points into the APEX engine, nothing more, nothing less.
If you rely upon functionality in your application which makes use of PL/SQL procedures not defined in this whitelist, this functionality will break when you specify the security.requestValidationFunction. I often encounter customers who invoke PL/SQL procedures in their application schema to download files, but there are better (and more secure) ways to do this, which would not break when implementing this whitelist.
Like any change to infrastructure or configuration, you should thoroughly test your applications with this setting prior to introducing it into a production environment. But if one or two things break because of this change, don't use that as an excuse to not implement this configuration change. Identify the issues and correct them. While there is a method in place to extend the whitelist, in practice, this should be seldom used.
If you're using ORDS as a mod_plsql replacement for your PL/SQL Web Toolkit application and not using APEX, then please avoid this configuration setting. APEX typically won't be installed in your database, and the whitelist will be irrelevant for your application.
The function wwv_flow_epg_include_modules.authorize has been around for more than 10 years (our teammate Scott added it in 2005), and it has been a part of the embedded PL/SQL Gateway and mod_plsql default configuration for a long time. And while it has been documented for use with ORDS, a reasonable person might ask why this isn't simply part of the default configuration of APEX & ORDS. I did confirm with the ORDS team that this will be included in the default configuration when using the PL/SQL Gateway of ORDS, beginning in ORDS 3.0.7.