Security posture and operating limits

Ballast is a local, self-directed trading application. Its dashboard is for the signed-in computer user. It is not a multi-tenant hosted trading service, and must not be exposed through port forwarding or a public reverse proxy.

Credentials and private data

Saved broker/API credentials, including all eight news-provider keys, are protected with Windows DPAPI before they are written to the database. OAuth token files use the same protection. Existing plaintext credential rows and legacy token files are upgraded when loaded. Unsupported operating systems refuse credential persistence instead of silently writing plaintext.

DPAPI binds decryption to the Windows user and machine. It protects a copied database from straightforward use elsewhere; it does not protect against malware already running with that user's privileges. Balances, settings, and trade history are private data but are not encrypted as an entire database. Protect the Windows account, disk, and filesystem permissions accordingly.

New installs keep data in the local user profile, outside normal OneDrive document folders. Existing ledgers remain in their original location until an explicit offline migration succeeds. This prevents accidentally starting a second empty portfolio. System shows the storage location and migration need. Stop all Ballast processes before migrating; verify the destination before removing the old copy. Never put a live SQLite database on a shared/network drive.

An upgrade cannot erase old cloud version history, backups, or previously shared auth logs. Older auth debug logs could contain tokens. If those files were exposed, remove copies where possible and rotate affected credentials. Use the encrypted dashboard key entry; do not store keys in .env or paste tokens/logs into public bug reports. Redact credentials before sharing diagnostics.

Dashboard and execution protections

The dashboard binds loopback and requires a local-user session cookie for

private data and actions. The launcher reads a DPAPI-protected access secret and passes it through a URL fragment to a minimal unlock page. That page clears the fragment before exchanging it for an HttpOnly, SameSite=Strict cookie. The secret never enters the HTTP request URL or access log. The cookie expires after eight hours and survives an ordinary app update/restart; reopen Start Ballast when it expires. Bare localhost access cannot read portfolios, backups, or API schemas, or place orders.

Exact Host/Origin checks and an independent per-process CSRF token remain

required on app mutations. Public routes expose only the unlock page, static assets, credential exchange, and version-only health check. This boundary blocks another unprivileged Windows account from simply calling the API; it cannot defend against an administrator, same-user malware, stolen browser credentials, or an attacker able to modify the installed application files. Keep installation and profile directories private to the Windows account.

Feed, broker, AI, and cached values are untrusted. Text/attribute escaping,

separately encoded JavaScript arguments, and HTTP(S)-only external URLs are required. Known injection paths have hostile-rendering regression tests. New rendering code still requires review.

Paper/live execution is explicit. FORCE_PAPER overrides live routes. Current

Terms and deliberate confirmation are required before enabling live trading. Options execution remains disabled server-side; Finance is research only.

Live order intents are persisted before submission. Equity confirmations must

match the exact broker ID/client reference, account, and symbol. Unknown or partial fills are never replaced with quote estimates. Persistent holds block duplicate submissions across restarts.

If a broker response or ledger settlement is ambiguous, inspect actual broker

orders and the local ledger. The symbol may remain blocked, including a later attempted stop order, until reconciled. Do not clear a hold merely to retry. Historical pending options intents remain visible for manual reconciliation; the current app does not enable new options submissions.

Owner reserves and per-account bounds are separate from bot-owned positions.

An unknown/ambiguous account selector is rejected rather than falling back to another account. Consequential actions are audited without secret values.

The loss breaker blocks new entries while exits remain available. The explicit

STOP file halts all trading. Licensing, updates, and subscription availability must not disable safety exits.

Startup, updates, and dependencies

Automatic startup is optional and reversible from System. Normal launches, watchdog checks, and update helpers run without flashing terminal windows. Do not disable antivirus or UAC, add broad exclusions, or weaken execution policy as an installation workaround.

Signed manifests and archive/file hashes authenticate eligible updates. The trusted verification key is bundled with the app; it is not accepted from the same downloaded archive. Unsigned, altered, downgraded, or unsafe-path packages are refused. Updates patch managed program files and preserve private state, with rollback copies for changed files. They are not binary delta downloads.

Review update results after restart. Interrupted file writes, power loss, or process termination may need manual rollback; do not assume a downloaded patch has installed successfully. Older unsigned update clients need one trusted manual upgrade. Every download and app title should identify the version.

Dependencies are pinned with artifact hashes and installed through reviewed locks. The release gate checks a fresh known-vulnerability report against those exact locks. Zero known findings is not a guarantee that packages are secure. Hash verification prevents an artifact changing unexpectedly; it does not establish that the reviewed artifact is benign.

Honest limits and public-release review

Unsigned executables/scripts can still trigger reputation-based antivirus or SmartScreen prompts even when source review and vulnerability checks pass. Authenticode signing, release provenance, a reproducible inventory, and clear installation behavior improve trust; never promise that every scanner will report zero concerns.

The local audit hash chain can reveal edited records relative to a trusted copy, but a same-user attacker can rewrite the entire database and chain. Backups contain private trading history and must be protected. DPAPI backup recovery across users/machines requires re-entering keys rather than assuming the encrypted credentials are portable.

The public website needs its own abuse controls, authenticated invite/update eligibility, privacy/retention policy, and incident response. Persistent install IDs are pseudonymous telemetry, not proof of anonymity. Community sharing must remain explicit opt-in with documented fields.

Before broad commercial release, review broker/data-provider permissions, research and performance claims, hypothetical-results disclosures, privacy, referral/marketing practices, and applicable legal obligations with qualified counsel. A security scan or "software, not advice" disclaimer does not resolve those questions. Consult RELEASE-PROCEDURE.md (RELEASE-PROCEDURE.md) for the mandatory engineering gates and OPERATIONS.md for operation.