¶ 
SQLite Security & Hardening
SQLite has no server process by default, so security is mostly about file access, key handling, and application behavior. This guide reflects security best practices for SQLite 3.51.2+.
¶ 
1. File Permissions and Ownership
- Store database files outside world-readable paths.
- Use dedicated service users and restrictive permissions:
# Set proper ownership and permissions
sudo chown app:app /srv/myapp/data/app.db
sudo chmod 640 /srv/myapp/data/app.db
# Also apply to WAL and SHM files
sudo chown app:app /srv/myapp/data/app.db-*
sudo chmod 640 /srv/myapp/data/app.db-*
- Apply the same controls to journal/WAL files and backup files.
- Use dedicated data directories with restricted access:
sudo install -d -o app:app -m 750 /srv/myapp/data
¶ 
2. Protect Against Unsafe Input
SQLite is embedded in the application process, so injection protection is an app responsibility.
- Always use parameterized queries.
- Avoid string concatenation for SQL.
- Validate untrusted inputs at the API boundary.
- Implement input length limits to prevent DoS attacks.
¶ Runtime Security Pragmas (for untrusted SQL)
For applications that must execute untrusted SQL, use these security pragmas:
-- Prevent SQL from corrupting the database
PRAGMA recursive_triggers = OFF;
-- Limit query complexity
PRAGMA max_page_count = 1073741823; -- Max database size
PRAGMA mmap_size = 0; -- Disable memory mapping for untrusted data
¶ Authorizer Function
Implement an authorizer to restrict SQL operations:
int auth_callback(void *user_data, int action, const char *arg1,
const char *arg2, const char *arg3, const char *arg4) {
// Return SQLITE_OK to allow, SQLITE_DENY to deny
// Customize based on your security requirements
}
sqlite3_set_authorizer(db, auth_callback, NULL);
¶ 
3. Encryption at Rest
SQLite does not provide built-in transparent encryption in standard builds.
¶ Recommended Options:
-
Full-disk encryption (LUKS/dm-crypt) for host-level protection:
# Example LUKS setup for database partition sudo cryptsetup luksFormat /dev/sdX sudo cryptsetup luksOpen /dev/sdX encrypted_db sudo mkfs.ext4 /dev/mapper/encrypted_db -
SQLite Encryption Extension (SEE) - Proprietary solution from SQLite authors:
- Requires licensing
- Provides AES-256 encryption
- Transparent to applications
-
SQLCipher - Open-source solution with 256-bit AES encryption:
- Drop-in replacement for SQLite
- Compatible with standard SQLite applications
-
Application-level encryption - Encrypt data before storing in SQLite.
¶ 
4. Secure Backup Handling
- Backups are plain database files unless separately encrypted.
- Encrypt backup artifacts and restrict access.
- Test restore procedures and integrity checks (
PRAGMA integrity_check;).
¶ Encrypted backup example:
# Create encrypted backup
sqlite3 /srv/myapp/data/app.db ".backup '| gpg --encrypt --recipient admin@company.com > /backups/app-$(date +%F).db.gpg'"
# Or compress and encrypt
sqlite3 /srv/myapp/data/app.db ".backup '| gzip | gpg --encrypt --recipient admin@company.com > /backups/app-$(date +%F).db.gz.gpg'"
¶ 
5. Application and Host Hardening
- Keep the SQLite library up to date through OS packages (latest: 3.51.2).
- Run apps under least-privilege service accounts.
- Use MAC controls (AppArmor/SELinux) to limit file paths an app can access.
- Implement resource limits to prevent DoS:
# Example systemd service with resource limits
[Service]
User=appuser
MemoryMax=512M
TasksMax=100
¶ Security Configuration for Untrusted Data
When processing untrusted database files or SQL:
-- Disable potentially dangerous features
PRAGMA trusted_schema = OFF; -- Don't trust schema from db file
PRAGMA cell_size_check = ON; -- Extra validation
PRAGMA mmap_size = 0; -- Disable memory mapping
PRAGMA temp_store = MEMORY; -- Force temp data to memory
¶ 
6. WAL and Temp Data Security
- WAL mode can leave additional files (
-wal,-shm) with sensitive data. - Secure temp directories and avoid shared world-writable paths when possible.
- Monitor and clean up WAL files regularly.
# Check for orphaned WAL/SHM files
find /srv/myapp/data -name "*.db-*" -mtime +1 -exec ls -la {} \;
¶ 
7. Logging and Auditing
- Add application-level logging for sensitive operations.
- Track schema migration changes and privileged maintenance tasks.
- Monitor database access patterns for anomalies.
¶ Audit Trail Script
#!/bin/bash
# Simple audit trail for database access
LOG_FILE="/var/log/sqlite-access.log"
echo "$(date): $(whoami) accessed $(basename $1)" >> $LOG_FILE
¶ 
8. Additional Security Measures for 3.51.2+
With SQLite 3.51.2+, you can leverage new security features:
- Defensive mode: Use
SQLITE_DBCONFIG_DEFENSIVEto prevent SQL statements from corrupting the database - Input limits: Reduce default limits to prevent DoS attacks
- Trusted schema: Use
PRAGMA trusted_schema=OFFwhen opening untrusted database files
¶ 
9. Security Monitoring
Monitor these aspects of your SQLite deployment:
- Database file permissions and ownership
- Unusual access patterns
- Database size growth (potential DoS)
- WAL file accumulation
- Application error logs for SQL injection attempts