Resistance To Attack

Small. Fast. Reliable.
Choose any three.
Resistance To Attack

# 1. SQLite Always Validates Its Inputs

SQLite should never crash, overflow a buffer, leak memory, or exhibit any other harmful behavior, even with presented with maliciously malformed SQL inputs or database files. SQLite should always detected erroneous inputs and raise an error, not crash or corrupt memory. Any malfunction caused by an SQL input or database file is considered a serious bug and will be promptly addressed when brought to the attention of the SQLite developers. SQLite is extensively fuzz-tested to help ensure that it is highly resistant to these kinds of errors.

Nevertheless, bugs happen. If you are writing an application that sends untrusted SQL inputs or database files to SQLite, there are additional steps you can take to help prevent zero-day exploits caused by undetected bugs:

## 1.1. Untrusted SQL Inputs

Applications that accept untrusted SQL inputs should take the following precautions:

1. Set the SQLITE_DBCONFIG_DEFENSIVE flag. This prevents ordinary SQL statements from corrupted the database file.

2. Consider using the sqlite3_set_authorizer() interface to limit the scope of SQL that will be processed.

## 1.2. Untrusted SQLite Database Files

Applications that accept untrusted database files should do the following:

1. Run PRAGMA integrity_check or PRAGMA quick_check on the database first, prior to running any other SQLite, and reject the file if any errors are detected.

2. Enable the PRAGMA cell_size_check=ON setting.

# 2. Summary

The precautions above are not required in order to use SQLite safely with potentially hostile inputs. However, they do provide an extra layer of defense against zero-day exploits and are encouraged for applications that pass data from untrusted sources into SQLite.