Security and trust

Built to protect the account, not just the interface.

The moment someone connects a broker, the standard changes. This page explains how Tidava handles keys, user isolation, access control, and the kind of security language a serious platform should use.

Start Free Trial → See Signal Pages
Credentials
Encrypted
Sensitive broker fields are stored encrypted at rest.
User scope
Isolated
One user should not see another user’s broker configuration or private state.
Admin access
Restricted
Sensitive routes are locked down more tightly than normal product flows.
Login defense
5x lockout
Repeated failed attempts trigger temporary lockout and audit tracking.
Best practice
Trading-only
Use keys without withdrawal permissions whenever your broker supports that split.

What we protect

A terminal can look polished and still handle sensitive data badly. The goal here is simple: keep credentials, account state, and user-specific settings protected and correctly scoped in normal use.

Broker credentials. API keys and related secret fields should be encrypted at rest and never echoed back casually into the UI.
Per-user state. Preferences, account selections, and private data should stay scoped to the signed-in user instead of leaking across sessions.
Admin controls. Sensitive operations deserve tighter routing, stronger access checks, and a smaller blast radius if a session is abused.

Encryption at rest

Stored broker secrets are treated as sensitive material, not general app settings. Public pages should say this clearly without pretending that encryption removes all operational risk.

Access and origin controls

Session checks, trusted host handling, rate limits, and tighter upstream/origin exposure reduce easy abuse and make direct scraping or brute-force attempts harder.

User-visible controls

People should be able to rotate, replace, or remove broker credentials and understand what kind of key is safest to connect.

What we never claim

Strong security copy is precise. Weak security copy sounds absolute. That is not the standard we want.

Not “unhackable.” No public web platform should say that.
Not “guaranteed safe.” Security is layers, monitoring, and sensible limits, not magic wording.
Not vague hype. Trust pages should explain what is protected, what users control, and what good operational behavior still matters.

Can another user see my broker balance?

No user should see another user’s private broker data. Balance and broker-level account details should only be shown when they belong to that signed-in user and the product flow is intended to expose them.

Should I use withdrawal-enabled keys?

No. The safest default is a trading-only key without withdrawal permissions whenever the broker offers that split.

Does Tidava replace my judgment?

No. Tidava is a market-analysis and trading-support platform. It is built to help users read the market more clearly, not to become a licensed adviser substitute.

Security belongs beside Education and Pricing

For a trading terminal, trust is not footer copy. It belongs beside Education and Pricing because users decide whether to connect anything sensitive long before they become long-term customers.

Education

Explains how to read a signal and how to think with the product.

Security

Explains how accounts, keys, and access are handled so trust is earned before a connection is made.

Risk disclosure

Explains clearly that trading involves risk and that analysis does not guarantee results.