Security and responsible disclosure

This document describes TradeStat’s public security principles and rules for good-faith vulnerability reporting. It does not disclose configurations, keys, internal addresses, or other information that could weaken protection.

The site remains a preview without real exchange connections. Its text editorial backend and transitional central-AuthServer sign-in are active, while seamless browser SSO, central-session refresh/revocation, and the trading production environment are not yet connected.

Controls are selected according to risk, data sensitivity, and current threats. The live preview has protected transport, restricted SSH access, security headers, and basic health checks. The items below define the required production baseline; environment separation, private networking, off-site backups, monitoring, and recurring audits are not represented as complete until separately verified.

• Data minimization and a prohibition on secrets in URLs, product analytics, and ordinary logs.
• Separation of production and staging, private networks for databases and queues, and no public PostgreSQL or Redis ports.
• Least privilege, separate user and administrator roles, and server-side authorization for every protected action.
• Encryption in transit, secret management outside the repository, and tested off-server backups.
• Logging of critical events without exchange keys, passwords, tokens, or trading payload contents.

In the transitional flow, the TradeStat form sends the login and password to its same-origin server over HTTPS. The server immediately forwards them to the central AuthServer only in request memory and neither stores nor logs the password. The returned token is not sent to the browser, decoded for role assignment, or persisted in the database.

After successful verification, the browser receives only a random HttpOnly TradeStat session lasting up to 30 minutes; PostgreSQL stores only a keyed session HMAC and a pseudonymous identity HMAC. The dashboard checks that session server-side, while the admin area additionally requires a locally assigned superadmin role. This is a shared account with a separate TradeStat session, not seamless browser SSO.

Before real sources are connected, TradeStat must accept only the minimum required read-only keys, without withdrawal permission and, unless a reviewed feature requires otherwise, without trading permission. Key permissions are checked during connection, and unsuitable keys are rejected.

Secrets are encrypted at the application layer while the encryption key is kept separately from the database. Decryption is available only to dedicated workers for the duration of a request. Key values, tokens, complete exchange responses, and financial data are prohibited in analytics, URLs, and unprotected logs.

A public security address and encrypted reporting channel will be published before production launch. Until that channel is listed, the site does not grant permission for active testing; please do not bypass access controls, scan other accounts, or attempt to extract data.

Once the channel is published, a useful report should include the affected URL or component, clear reproduction steps, an impact assessment, and a safe proof of concept without personal data. TradeStat will acknowledge the report, investigate it, and provide status updates where possible. No reward program applies unless expressly announced.

• Do not use social engineering, phishing, physical attacks, or denial of service.
• Do not alter or delete data, retain another person’s information, and stop at the first sign of access to it.
• Do not publish details until a reasonable remediation period has been agreed.
• Do not present an automated scanner result as a confirmed vulnerability without validating impact.

Production must have an internal response plan, named responders, an incident register, backup communication channels, and tested recovery procedures. The team classifies an event, contains its impact, preserves necessary evidence, removes the cause, and verifies recovery.

If an incident affects personal data, users and supervisory authorities are notified to the extent and within the periods required by applicable law. A public policy does not replace the internal runbook and does not reveal details useful to an attacker.

Use a unique password for the central account, enable multi-factor protection, verify the domain before signing in, and never give support staff codes, tokens, or keys. Create a separate exchange key with read-only minimum permissions and revoke unused keys regularly.

If compromise is suspected, terminate active sessions, revoke the relevant exchange keys through the exchange, and use the official reporting channel once published. Do not send secrets in ordinary email or a public message.

No system can guarantee absolute security. TradeStat must maintain controls proportionate to risk, test their effectiveness, and correct confirmed weaknesses, but this document is not a guarantee that incidents cannot occur.

The policy is updated when the architecture, reporting channels, or disclosure program changes. Material revisions receive a new version and date; prior versions should remain in the document archive.