SQLite has a cheap, for-fee extension called SQLite Encryption Extension.

Without even looking at the feature: You have a webserver stupidly serving the encrypted database file. And some code (Perl script, whatever) that holds the key to the encrypted database. All that an attacker now needs is either a second misconfiguration that allows reading the perl script (or whatever binary cooperates with the webserver) to get the key, or a flaw in the SQLite encryption.

The clean way is to place the database file somewhere outside the document root of the web server. Encrypting it does not hurt, except when you have performance issues. But as long as you provide both the encrypted file and the en-/decryption key (it must be a symmetric key), all encryption is just expensive obfuscation.

Oh, and by the way: The second misconfiguration does not have to be in the web server. A simple bug in a CGI script may be sufficient. One of my favorite ones was in gzip_cnc, partly because I caused that red security warning at the top of the page. gzip_cnc runs as a CGI, and up to version 1.10, it did not validate which files it compressed and returned to the browser (see security). If you appended any URL, it bypassed all webserver security measurements and returned any file, nicely compressed with gzip. Including its own code, the code of any CGI, the contents of every file accessible to the webserver. No passwords required, all limits bypassed.

Alexander