#define SQLITE_DETERMINISTIC 0x000000800 #define SQLITE_DIRECTONLY 0x000080000 #define SQLITE_SUBTYPE 0x000100000 #define SQLITE_INNOCUOUS 0x000200000
These constants may be ORed together with the preferred text encoding as the fourth argument to sqlite3_create_function(), sqlite3_create_function16(), or sqlite3_create_function_v2().
The SQLITE_DIRECTONLY flag is recommended for any application-defined SQL function that has side-effects or that could potentially leak sensitive information. This will prevent attacks in which an application is tricked into using a database file that has had its schema surreptiously modified to invoke the application-defined function in ways that are harmful.
Some people say it is good practice to set SQLITE_DIRECTONLY on all application-defined SQL functions, regardless of whether or not they are security sensitive, as doing so prevents those functions from being used inside of the database schema, and thus ensures that the database can be inspected and modified using generic tools (such as the CLI) that do not have access to the application-defined functions.
SQLITE_INNOCUOUS is similar to SQLITE_DETERMINISTIC, but is not exactly the same. The random() function is an example of a function that is innocuous but not deterministic.
Some heightened security settings (SQLITE_DBCONFIG_TRUSTED_SCHEMA and PRAGMA trusted_schema=OFF) disable the use of SQL functions inside views and triggers and in schema structures such as CHECK constraints, DEFAULT clauses, expression indexes, partial indexes, and generated columns unless the function is tagged with SQLITE_INNOCUOUS. Most built-in functions are innocuous. Developers are advised to avoid using the SQLITE_INNOCUOUS flag for application-defined functions unless the function has been carefully audited and found to be free of potentially security-adverse side-effects and information-leaks.
See also lists of Objects, Constants, and Functions.
*** DRAFT ***