Small. Fast. Reliable.
Choose any three.

This information is obsolete. You are looking at the CVSTrac source management system display for SQLite that was replaced by Fossil on 2009-08-11. The information shown here has not been updated since that cut-over. These pages are retained for historical reference only.

Note: If you came here looking for a commercial solution to encrypt SQLite Databases, head over to the official SQLite professional Support page.

As SQLite databases are not encrypted or password-protected by default, ways of maintaining their security should be found. When an SQLite database is stored on the file system of your server, if it's stored in a location that is "web accessible" (whether this URL is announced or not) it is possible that this could be found, downloaded, and exploited. If you don't keep sensitive information in an SQLite database, and don't mind that others see the stucture of your backend databases, this might not be an issue for you. However, in most cases, it is.
This isn't an SQLite-specific problem, as this problem exists in other different important files, exposed to a remote user (.inc, .class, .conf)...
Not that the security of SQLite needs to be enhanced, rather, implementers of SQLite databases should be aware of the security implications and use common sense.

  • In the Zend SQLite tutorial (which is a must-read for all aspiring SQLite users), they suggest that you use the following syntax to open a database:

      $db = $_SERVER['DOCUMENT_ROOT']."/../database.sdb";
      $handle = sqlite_open($db) or die("Could not open database");

    That makes a lot of sense, and is a simple way to ensure that the database is outside your DocumentRoot. An Sqlite database is a binary file. If you do not want to have people being able to download it, do not put it inside a web accessible directory. (Suggested by Aaron Wormus)

  • If the database has to be stored in one of your web accessible directories just drop the following in a .htaccess in the same directory:

      <FilesMatch "\.(sqlite|sdb|s3db)$">
      Deny from all
      </FilesMatch>

    This way it won't be possible to download the database from a remote computer. (Suggested by Aaron Wormus)

  • Another trick you can do is to give your sqlite database a .php extension and create a table that would cause PHP to generate a parse error when trying to send the database to the user. That is, create a table named '<?php'. This will make it impossible for people to download the data inside your database. (Suggested by Ilia)

  • Latest versions of DB_Sqlite_Tools support the insertion and retrieval "on the fly" of encrypted data to/from an SQLite database.

  • Limiting scope for damage - On public access systems that provide a database, the scope for damage should be limited to the database itself. and a compromised administrative account should not be capable of accessing or damaging resources outside of the database container. Policy document relating to security of public access systems