Security

Version 1.0Effective 24 August 2026

1. Security in plain language

Propcockpit connects to trading accounts and can, when you explicitly authorize and arm the relevant functions, send trading instructions. That access deserves a precise explanation.

This page describes controls that are active in the Service and the limits of those controls. It is not a certification, guarantee, audit report or promise that an incident can never occur. Propcockpit does not claim SOC 2, ISO 27001, PCI DSS certification or any other certification unless that claim is expressly added after it has been earned and independently verified.

Security questions and vulnerability reports may be sent to info@propcockpit.com.

2. Broker authorization

Your broker password never reaches Propcockpit

You connect a supported account through Spotware’s official cTrader OAuth flow. Authentication occurs on Spotware’s or cTrader’s pages. Propcockpit does not ask for, receive or store your broker password.

Permissions are explicit

cTrader supports two relevant OAuth scope values. accounts permits view-only account information and statistics but does not permit trading. trading permits account information, statistics and the trading operations allowed by the broker and cTrader Open API. Propcockpit requests the scope shown during connection, and you approve access on the provider’s authorization screen.

A trading scope can permit Propcockpit to place, modify and close orders. It cannot be used by Propcockpit to withdraw or transfer funds from your broker account.

You can disconnect the account in Propcockpit and can revoke access independently through your cTrader or Spotware settings. Revocation stops the token from being usable after the provider processes it.

3. Token and secret protection

Broker OAuth access and refresh tokens are encrypted at rest using envelope encryption with AES-256-GCM. Each connected broker account receives a separate data-encryption key. Those keys are themselves encrypted with a key held outside the application database, so a database copy alone is not sufficient to decrypt the tokens.

Rotating that outer key re-seals only the small per-account keys, so a rotation does not require any user to reconnect. Broker tokens are handled server-side, are never sent to the client browser and are not written to application logs.

Where Propcockpit issues a webhook secret, the secret is displayed at creation and is not shown again. Only a SHA-256 digest of it is stored, and a presented secret is compared against that digest in constant time. You should rotate or revoke a secret immediately if you believe it has been exposed.

4. Trading actions and fail-closed behavior

Connecting an account does not silently authorize every automation. Trading functions must have the required cTrader permission and must be enabled or armed in Propcockpit before the relevant automated write is attempted.

Before every broker write, Propcockpit evaluates every required precondition against sufficiently current account state and the applicable active rules. If a required precondition is unknown, stale or cannot be verified, Propcockpit does not send the write. If uncertainty arises after a write or for a broker-direct position, the Service marks the item unprotected and instructs you to verify it at the broker.

Orders placed through Propcockpit require a broker-side stop-loss. The order and stop instruction are sent to the broker. A broker may reject, modify or delay either instruction. Propcockpit displays the resulting state and treats a position without the confirmed protection as unprotected rather than assuming that a requested stop exists.

Positions opened directly at the broker can be read and counted after the event. They were not subject to Propcockpit’s pre-trade checks. In version 1, a cross-account risk number is shown for information and is not itself an enforced portfolio limit.

5. Auto-flatten and recovery

When an enabled protection threshold is triggered, Propcockpit attempts a two-step action:

1. close relevant open positions; and
2. cancel relevant pending orders.

Each broker response is recorded. If an action is rejected, times out or the broker cannot be reached, Propcockpit retries only according to its active execution policy and shows the unresolved state. When connectivity returns, the Service reconciles against the broker’s current state before deciding whether another permitted action is required.

Auto-flatten is not unconditional protection. It depends on the Service, broker, cTrader Open API, market and network being available, and on the account retaining valid permissions. Market closure, gaps, slippage, insufficient liquidity, rate limits, broker controls, concurrent modification, token revocation and other events can delay or prevent execution or produce a different price. Keep appropriate broker-side protection and monitor your broker account directly.

6. Webhook protection

For supported webhook integrations, Propcockpit uses secret verification, timestamp and nonce checks and replay protection before accepting an instruction. Invocation and validation results are logged so that the instruction and resulting action can be traced.

You must keep webhook URLs and secrets confidential, restrict senders where possible, use unique nonces and rotate a credential after suspected exposure. Do not place passwords, card information or unrelated personal data in a payload.

A valid webhook is an instruction, not proof that a trade will execute. The same broker, market, connectivity and risk checks that apply to other writes may reject or alter the result.

Third-party content, market data, alerts or webhooks may be used only within the license granted by that provider. Unless Propcockpit expressly identifies a written license that permits the exact use, the Service is not licensed, offered or permitted for use with TradingView-sourced content, market data, alerts or webhooks for automated trading, order generation, price referencing, order verification or automated risk-management actions. Do not send that material to an automated Propcockpit function.

7. Authentication, sessions and administrative access

Authentication and sessions are handled by Propcockpit itself, on our own server, rather than by an outside identity provider. Passwords are stored only as a one-way hash and are never recoverable, including by us. Session cookies are configured for authentication and security purposes.

Two-factor authentication with an authenticator app is available on every account, and we strongly recommend enabling it and storing your recovery codes somewhere safe. An administrative account cannot reach the admin area at all without it.

Administrative access is limited to authorized personnel with a work-related need. Administrative actions involving sensitive systems or user data are logged. The security audit trail is append-only, and that is enforced by the database itself: an UPDATE or DELETE against the admin audit table is refused, so no service administrator - and no application bug - can edit or erase an administrative audit event.

Access is reviewed and removed when it is no longer required. Support will never ask you to send a broker password, full payment-card number, authentication code or raw OAuth token.

8. Hosting and providers

Propcockpit runs on a server operated by DigitalOcean in London, United Kingdom, in their LON1 region. The website, the application, the market-data and order gateway and the database all run on that host. We do not use a third-party identity provider, a managed database service or an outside cache.

Beyond hosting, Propcockpit uses Stripe for payments, Resend for transactional email, Telegram for the alerts of users who connect it, and Google for users who choose to sign in with a Google account. Stripe processes payment-card data directly; Propcockpit does not store full card numbers or card security codes.

Providers are selected and configured according to the sensitivity of the function. Their availability and security remain external dependencies. See the Privacy Policy and the provider table for roles, locations, international transfers and personal-data handling.

9. Logging, monitoring and data minimization

Propcockpit logs authentication, authorization, broker-write, risk-rule, webhook and administrative events needed to operate, secure and explain the Service. Sensitive tokens and raw secrets are excluded from application logs by design. Access to production data and logs is restricted.

Logs are retained for defined periods and then deleted or anonymized, except where an event must be preserved for an active incident, dispute or legal obligation. Production data is not used as casual test data. Diagnostic information provided to support is limited to what is needed for the issue.

10. Incident handling

We investigate suspected security incidents, contain affected access, preserve relevant evidence, remediate confirmed causes and notify affected users or authorities when required by law.

If you believe your account is compromised:

1. disarm automated trading features where possible;
2. review open positions and pending orders directly with your broker;
3. revoke Propcockpit access in cTrader or Spotware;
4. secure your email and authentication account; and
5. contact info@propcockpit.com with the time, account identifier and a description, but no passwords or raw tokens.

11. Responsible vulnerability disclosure

Send vulnerability reports to info@propcockpit.com with the subject Security report. Include a clear description, affected URL or function, reproduction steps, impact and any safe proof of concept.

We will acknowledge a report within two business days and provide an initial status within five business days. Remediation time depends on severity and complexity. These commitments are not a paid-plan support resolution SLA.

When testing:

• use only accounts and data you own or have written permission to test;
• stop if you encounter another person’s data;
• do not access, change, download or retain data beyond the minimum needed to demonstrate the issue;
• do not disrupt availability, degrade trading or broker systems, send high-volume traffic, use social engineering or test physical security;
• do not publicly disclose an unresolved issue before we have had a reasonable opportunity to investigate and fix it; and
• comply with applicable law.

We do not currently promise a bug bounty or payment. Good-faith research that follows this policy will be handled constructively, but this policy is not permission to violate third-party terms or law.

12. Your role in security

Security is shared. You should:

• use a unique password and turn on two-factor authentication;
• keep your email, device, browser and broker account secure and updated;
• verify the domain and OAuth screen before authorizing access;
• grant only the permissions you need and revoke unused connections;
• review risk settings, protection status, positions and pending orders;
• keep webhook secrets and URLs private and rotate them after exposure;
• test settings with a demo account before using a live account; and
• maintain broker-side protections and an independent way to access the broker.

13. Current controls and certifications

This page describes current controls. A planned control is not treated as active until it is deployed, tested and documented here.

Propcockpit does not claim an independent security certification or audit unless the exact certification, scope, auditor and validity period are published here. Encryption, the choice of hosting region or the use of a certified provider does not by itself certify Propcockpit.

14. Contact

Security questions and vulnerability reports: