Skip to content

Security at My Trading Force

We treat the journal entries you trust us with as exactly that — yours. This page describes the controls that protect your account, your data, and the platform itself.

Last updated: 30 April 2026

1. Encryption

  • HTTPS is enforced on every domain via HSTS with a one-year max-age and includeSubDomains.
  • Passwords are stored as bcrypt hashes; we never store or log raw passwords.
  • Authentication tokens are signed JWTs with rotation on logout.
  • Database storage is encrypted at rest by our hosting provider.

2. Authentication and account protection

  • Email + password sign-in, plus OAuth via Google and GitHub.
  • Optional time-based one-time-password (TOTP) two-factor authentication.
  • Progressive account lockout after 5 failed attempts in 15 minutes — 15 minutes initially, doubling each time, capped at 24 hours.
  • Generic error messages on sign-in to prevent user enumeration.
  • All authentication events are logged for audit and abuse review.

3. Network and edge controls

  • Traffic terminates at Nginx with per-IP rate limiting using shared memory zones.
  • The Express application layer adds endpoint-specific rate limits (sign-in, signup, password reset, 2FA verification, AI endpoints).
  • Helmet adds security headers — HSTS, X-Content-Type-Options: nosniff, restrictive CSP, Referrer-Policy: strict-origin-when-cross-origin.
  • CORS is restricted to a per-environment origin allow-list.

4. Application security

  • Cross-site request forgery (CSRF) protection on every state-changing request via the double-submit-cookie pattern, signed with the JWT secret.
  • Database access via parameterised queries (Knex/Objection.js) — no string-concatenated SQL.
  • Server-side input validation on all routes via express-validator.
  • Role-based access control with ownership checks on every record.
  • API responses pass through a serializer that strips private fields before they leave the server.

5. Hosting and isolation

The application runs on DigitalOcean. The exact region is configured for EU residency where required. Production, staging, and local environments are fully isolated, with separate credentials, separate database clusters, and distinct cookie prefixes so tokens cannot leak between them.

6. Logging, monitoring, and incident response

  • Application logs include request context, user IDs, and outcomes — but not passwords or token contents.
  • Errors are captured by our error-tracking provider with personal data minimised at source.
  • We have a documented incident-response runbook for confirmed security events covering containment, eradication, recovery, and post-mortem review.
  • Where required by GDPR Art 33, we will notify the relevant supervisory authority within 72 hours of becoming aware of a personal-data breach, and affected users where the breach is likely to result in high risk.

7. Responsible disclosure

If you believe you have found a security vulnerability, please email us at [email protected] before disclosing it publicly. Include reproduction steps, affected components, and your assessment of impact.

Our commitments to good-faith researchers:

  • We acknowledge reports within 3 business days.
  • We will not pursue legal action against research that follows this policy: no data exfiltration beyond what is necessary to demonstrate impact, no degradation of service, no targeting of other users' accounts without explicit permission.
  • We will keep you updated as we triage, fix, and verify.
  • With your consent we will credit you in our changelog once the fix has shipped.

8. OWASP Top-10 alignment

RiskHow we mitigate
A01 Broken access controlPer-record ownership checks; CASL-style role abilities.
A02 Cryptographic failuresTLS enforced via HSTS; bcrypt password hashes; signed JWTs.
A03 Injection Parameterised SQL; express-validator input validation.
A04 Insecure designDefence in depth: edge limits, app limits, lockout, RBAC.
A05 Security misconfiguration Helmet headers, restrictive CSP, environment-specific config.
A06 Vulnerable componentsDependabot monitoring; regular dependency updates.
A07 Authentication failuresAccount lockout, rate limiting, optional 2FA.
A08 Data integrity failuresCSRF double-submit; output serialisation.
A09 Logging and monitoringAction logs, observability context, error tracking.
A10 Server-side request forgeryNo user-controlled URL fetching in critical paths.

9. Compliance posture

My Trading Force is in open beta. We work to GDPR as our baseline and are actively building toward more formal attestations. We do not currently hold a SOC 2 or ISO 27001 certification; if your organisation requires one to use the service, please reach out and we will share our roadmap.

10. Related documents