Ensure that SQLite file is not public

[spacedmonkey]

Cache could contain sensitive data and should not be publicly available. I was able to download the file in browser by going to

localhost:8889/wp-content/.ht.object-cache.sqlite

The permission should be set to make this file not public.

[OllieJones]

It's already possible to put the .sqlite file outside the document root by setting WP_SQLITE_OBJECT_CACHE_DB_FILE in wp-config.php. It looks like further fixes will require creating a subdirectory containing a .htaccess file with these contents.

Order deny,allow Deny from all

[spacedmonkey]

It is worth noting the default of writing to wp-content isn't the best idea. In many server configs, wp-content is not writable, so this will fail.

I wonder if we can use chmod to change the permissions.

[OllieJones]

This plugin's activation process (from the dashboard) requires writing the drop-in, copying it from assets/drop-in/object-cache.php to wp-content/object-cache.php . If wp-content isn't writable the plugin can't be activated from the dashboard.

A site without the whole plugin, but with the drop-in, functions correctly. If that's the installation discipline, the site manager can also set WP_SQLITE_OBJECT_CACHE_DB_FILE.

This drop-in business is (unreasonably) brittle.

[SS88UK]

It is worth noting the default of writing to wp-content isn't the best idea. In many server configs, wp-content is not writable, so this will fail.

I wonder if we can use chmod to change the permissions.

@spacedmonkey Lots of sensitive data is stored within wp-content, most notably full website backups. These are protected via .htaccess and random strings, the latter is still open to brute force.

Apache .htaccess example to block all files starting with .ht

<FilesMatch "\.(ht)">
  Require all denied
</FilesMatch>

My current installations of NGINX, LiteSpeed, and Apache all come with the above (and that wasn't me that added it). What platform and/or service are you using?

@OllieJones I think a good idea would be to generate a random string upon installation/activation for this file (if nothing is set) - that way there's more security, although brute forcing can still happen, it's ultimately up to the end-user to secure their platform, right?

[OllieJones]

I have added support for WP_CACHE_KEY_SALT. A random string here (much like the other wp-config.php salt strings) obfuscates the .sqlite file names. And, you can use WP_SQLITE_OBJECT_CACHE_DB_FILE to relocate the file someplace besides wp_content.

I think those things address the security problem. If not, please open another issue.