Skip to content

Security: A350Fan/Purchase-Statistics

SECURITY.md

Security Policy

Supported Versions

Purchase Statistics is currently an early prototype. Security fixes are intended for the actively maintained development branch and the latest published release, if releases are available.

Older forks, local modifications, and outdated builds may not receive security fixes.

Reporting a Vulnerability

Please report security issues privately whenever possible.

Preferred reporting options:

  • Use GitHub Private Vulnerability Reporting or a GitHub Security Advisory for this repository, if available.
  • If private reporting is not available, open a minimal public issue asking for a private contact path. Do not include vulnerability details in the public issue.

Please include:

  • A short description of the issue
  • Steps to reproduce the issue
  • The affected target platform, for example Windows, Linux, or Android
  • The app version, commit, or branch you tested
  • Any relevant logs or screenshots with secrets removed

Do not include:

  • Steam Web API keys
  • Steam passwords or authentication cookies
  • Private Steam account details
  • Local SQLite databases
  • Full CSV exports containing real purchase data
  • Length-estimate CSV imports/exports if the listed games or Steam App IDs should stay private
  • Screenshots that show secrets, personal purchase data, or private profile data

Security Scope

Security reports are especially useful for issues involving:

  • Exposure or unsafe handling of Steam Web API keys
  • Local database, CSV import, or CSV export data leaks
  • Unsafe file handling during import, export, backup, or restore flows
  • Unintended network requests
  • Incorrect assumptions around Steam profile data, Steam App IDs, or cached Steam Store data
  • Build, packaging, or dependency configuration issues

Issues in Valve or Steam services, Steam APIs, Steam accounts, or third-party infrastructure should be reported to the respective provider.

Local Data and Secrets

The app stores data locally and does not use a project-operated backend. The local SQLite database is not additionally encrypted by the app. The Steam Web API key is stored in platform secure storage where available, for example Windows credential storage, Android encrypted storage, or the Linux Secret Service/libsecret stack. Older plaintext keys from previous local databases are migrated to secure storage and cleared from SQLite after the migration attempt. If secure storage cannot accept a legacy key, the plaintext value is still removed from SQLite and the user must enter the key again. Steam sync errors shown in the app are sanitized so raw request URLs are not displayed. The API key should still be treated as a secret.

Users should avoid sharing databases, full CSV exports, logs, or screenshots unless sensitive data has been removed. The length-estimate CSV import/export is designed for sharing estimates without purchase stats, but it can still reveal listed games and Steam App IDs.

Release Signing

Android release builds require a local android/key.properties file that points to a private release keystore. Release builds intentionally do not fall back to the Android debug signing key. Signing files are ignored by Git and must not be committed.

Repository Leak Prevention

This repository includes guardrails to reduce the risk of publishing secrets or private local data:

  • .gitignore blocks local databases, CSV/XLSX exports, environment files, mobile signing keys, Firebase config files, and common secret file names.
  • tool/security_scan.dart scans tracked files by default, staged files with --staged, and reachable Git history with --history.
  • .githooks/pre-commit runs the staged scan before commits when enabled with git config core.hooksPath .githooks.
  • .githooks/pre-push runs the history scan before pushes when hooks are enabled.
  • .github/workflows/security.yml runs the same history-aware scan for pushes and pull requests.

Run the scan manually before publishing:

dart tool/security_scan.dart

These checks are a safety net, not a guarantee. If a real secret was committed or pushed, remove it from the repository, rotate the secret at the provider, and treat the exposed value as compromised.

Response Expectations

After a vulnerability report is received, the maintainer will try to:

  1. Confirm receipt of the report.
  2. Reproduce and assess the issue.
  3. Prepare a fix or mitigation when the issue affects this project.
  4. Credit the reporter if requested and appropriate.

Response times may vary because this is a personal open-source project.

Disclosure

Please avoid public disclosure until the issue has been reviewed and, where practical, a fix or mitigation is available.

There aren't any published security advisories