Critical Security Issue

PR #736 introduced a critical security vulnerability by changing the SQLite database path from ../../speedtest_telemetry.sql to __DIR__ . '/speedtest_telemetry.db'.

This places the database file inside the web-accessible results/ directory, allowing anyone to directly download the entire database by accessing:

https://example.com/results/speedtest_telemetry.db

This exposes:

• All IP addresses (regardless of redaction settings in the code)
• Complete test results and performance data
• Timestamps, ISP information, and geolocation data
• Any other telemetry stored in the database

Required Fix

Change line 13 in results/telemetry_settings.php:

Current (VULNERABLE):

$Sqlite_db_file = __DIR__ . '/speedtest_telemetry.db';

Required (SECURE):

$Sqlite_db_file = __DIR__ . '/../../speedtest_telemetry.db';

Why Two Directories Up?

According to the installation documentation (doc.md, line 43-44), users deploy the application like this:

• Copy files to webroot: /var/www/html/speedtest/
• This includes: index.html, speedtest.js, backend/, results/, etc.

The file structure is:

/var/www/html/speedtest/          <- webroot (web-accessible)
├── index.html
├── speedtest.js
├── backend/
├── results/
│   └── telemetry_settings.php   <- __DIR__ is here
└── examples/

Moving the database two directories up places it at:

/var/www/html/                    <- one level up from webroot
└── speedtest_telemetry.db        <- NOT web-accessible

Or even:

/var/www/                          <- two levels up from webroot  
└── speedtest_telemetry.db        <- NOT web-accessible

This matches the original intention of the ../../speedtest_telemetry.sql path before PR #736, which was designed to place the database outside the webroot for security.

What to Keep

Keep all the validation improvements from PR #736:

• Directory existence checks
• Directory writability checks
• Improved error messages in results/telemetry_db.php
• The .gitignore entries for *.db files

These are good improvements that help users diagnose permission issues.

Documentation Note

The documentation at line 86 of doc.md explicitly warns about this:

"If you chose to use SQLite, you might want to change $Sqlite_db_file to another path where you want the database to be stored. Just make sure that the file cannot be downloaded by users."

PR #736 violated this security requirement by placing the database in a web-accessible location.

Impact

This is a critical security vulnerability affecting all users who:

1. Use SQLite for telemetry storage (now the default since PR Fix SQLite database path to resolve "unable to open database file" error #736 changed $db_type to 'sqlite')
2. Have deployed the application since PR Fix SQLite database path to resolve "unable to open database file" error #736 was merged

The fix must be deployed urgently to prevent data exposure.