> So here is the case, if someone drops a malicious -wal file and connect to the same sqlite db we use by setting jounal_mode=wal, which will make that wal file take effect and risk all the data in the db. If a malicious attacker can "connect to the database" and "set wal mode" and "drop a malicious wal file" then there is no need to do so as that attacker can simply obliterate your database directly without going to all the bother and convolution. The predilection for this sort of construction is quite common where the pre-condition is "after obtaining root/system authority" the following X steps and Y vulnerabilities could be used to compromise the system. In actual fact, once the "obtain root/system authority" has been accomplished there is no further need for any vulnerabilities since you can simply do whatever dim sum (your little heart desires) without further ado. In other words, the correct response for securing against the situation you have posited is to not allow unauthorized access to the database nor to the filesystem containing the database, and this action is quite outside SQLite3's purview. In other words, the first defense against "anyone can come in the house and steal my computer and read everything that is on it" is not to hide the computer or encrypt the damn thing, or even to electrify the chassis, but rather to lock the doors! And if you are worried that someone might break down the door after you have locked it (or pick the lock) then perhaps a motion detector alarm system would be a good next step. There are quite a lot of steps that you can take before running 100,000 Volts through the computer chassis (with a backup power supply) is a necessary defensive step.