Security

How we protect your access.

Javlot reads your broker account through credentials you provide. Here is how those credentials are stored, what surrounds them, and what happens if something goes wrong.

Last Refresh: 05-05-2026

MT5 credentials are encrypted before they are stored

Every MT5 password you enter on Javlot is encrypted on the way in, using RSA-OAEP with a 4096-bit key pair. The public half of the key is what the application uses to encrypt. The private half lives only on our server, in an environment variable that the rest of the application cannot read directly.

Once encrypted, the credential is stored in the database as ciphertext. The plaintext value never sits at rest. Even an actor with read access to the database row would only see the encrypted blob, not the password itself. Decryption happens in-memory at the moment the platform needs to open a broker session, and the plaintext is discarded as soon as the session is established.

Key rotation is supported and rehearsed: the private key can be replaced and every stored credential re-encrypted in a single operation, without changing the application surface visible to users.

Two-factor authentication

Account login uses the Supabase Auth flow with email and password. Two-factor authentication (TOTP via authenticator app) is on the near-term roadmap and will be rolled out as an account-level opt-in once the dashboard UI for enrollment is shipped.

Until 2FA is live, the strongest protection you can apply is a unique, high-entropy password not reused on any other site, combined with the password manager of your choice. The login route already rate-limits brute-force attempts.

Where Javlot runs

HostingVercel, deployed from a GitHub-tracked repository.
DatabaseSupabase Postgres with row-level security enabled on every multi-tenant table.
Primary regionEU (eu-west, GDPR jurisdiction).
BackupsDaily database snapshots retained on the Supabase managed plan.

The application code itself is checked in. Every deploy ships from a versioned commit, every dependency is pinned in the lockfile, and every environment variable required for the build is validated by a pre-build script that fails the deploy if anything is missing.

If something goes wrong

We commit to disclose security incidents that materially affect user accounts within a reasonable window of detection. If credential storage is compromised, every affected user is contacted directly, the impacted credentials are invalidated, and a written incident summary is published on the Javlot domain.

If you discover a vulnerability, write to security@javlot.io. We acknowledge reports within two business days and do not pursue legal action against good-faith researchers who follow standard responsible-disclosure practice.

GDPR and your data

Javlot is a French SASU. GDPR applies. Users can request a full data export or full account deletion from the dashboard, and the deletion flow erases credentials, sessions, and personal identifiers, retaining only the minimum trade history required for accounting and audit obligations.

We do not sell user data. We do not share user-identifiable trade history with strategy providers: providers see their own trades on their source account, not the trades that occurred on user-side copies. Cookies used on the marketing site are limited to analytics that can be opted out of.

This page describes Javlot security posture at a high level. It is not a substitute for the terms of use or privacy policy, both of which carry the legally binding language. If a clause on this page conflicts with the legal documents, the legal documents take precedence.