Fuselit connects to your brokerage account and places real orders, so the security of that connection is the most important thing we build. This page describes the controls that protect your account and your data, what you can do to harden your own account, and how to report a vulnerability to us.
1. Your brokerage connection
There are two ways to connect a brokerage account, and both are designed so that the smallest possible amount of secret material reaches us:
- Authorize from your broker (OAuth) — you approve Fuselit on your broker's own website and your broker issues us an access token. We never receive your brokerage password, and we never receive your API keys. You can revoke the token at any time from the connected-apps section of your brokerage dashboard, which cuts our access immediately.
- API keys — if you paste an API Key ID and Secret Key instead, they are encrypted before they are written to the database and decrypted only in memory, at the moment an order or account request is made.
Either way, the connection is scoped to reading your account and market data and to placing and managing orders. One Fuselit account maps to one brokerage account at a time, and you can disconnect from Settings whenever you want; disconnecting deletes the stored credential.
2. Encryption
- In transit — the entire site is served over TLS. In production we send an HTTP Strict Transport Security header (one year, including subdomains), so browsers refuse to talk to us over plain HTTP at all.
- At rest — brokerage API keys, OAuth access tokens, two-factor secrets, and recovery codes are encrypted with Fernet (AES-128-CBC with HMAC authentication) before being stored. The encryption key lives in the runtime environment, never in the source repository.
- Passwords — stored only as bcrypt hashes with a per-password salt. We cannot read your password, and a password reset issues a new one rather than recovering the old.
3. Account security
- Two-factor authentication — optional TOTP 2FA (Google Authenticator, 1Password, Authy, or any compatible app), enabled from Settings. Recovery codes are single-use, bcrypt-hashed, and encrypted as a set, so neither a database read nor a backup copy exposes them.
- Session cookies — HttpOnly (unreadable by JavaScript), SameSite=Lax, and Secure in production. The "remember me" cookie expires after 30 days, so a stolen cookie has a bounded lifetime.
- CSRF protection — every state-changing request requires a session-bound CSRF token, so another site cannot make your browser act on your Fuselit account.
- Rate limiting — login, registration, password reset, and two-factor verification are rate limited per account and per IP address to blunt credential-stuffing and brute-force attempts.
- Security email — enabling or disabling two-factor authentication, or regenerating recovery codes, sends you an email stamped with the time and IP address, so you learn about a change you did not make. Password resets are delivered only to your registered address as a single-use link that expires in one hour.
4. Infrastructure
- The application and its PostgreSQL database run on a managed cloud platform in the United States. Database traffic stays on the provider's private network and is not exposed to the public internet.
- Secrets (encryption keys, brokerage credentials, third-party API keys) are supplied as environment variables at runtime. They are not committed to source control.
- Dependencies are declared in a single manifest, and updates — including security patches — ship through the same reviewed deployment pipeline as any other change.
- Application and access logs are retained for debugging and abuse investigation, and are not used for advertising.
5. Payments
Subscription payments are processed by Stripe. Card details are entered directly into Stripe's hosted checkout and never pass through Fuselit's servers — we store only limited billing metadata such as plan, status, and the last four digits of the card. We are not able to charge a card outside the subscription you signed up for.
6. Third parties we rely on
We keep the list of vendors that can touch your data deliberately short:
- Your brokerage — custody of your funds and securities, and order execution.
- Our cloud host — application hosting and the managed database.
- Stripe — subscription billing.
- Our transactional email provider — account, security, and alert email.
- Market data providers — quotes and fundamentals. These receive symbols, not your identity or positions.
What each of them receives, and why, is described in the Privacy Policy.
7. What we do not claim
We would rather be precise than impressive. Fuselit is an independent, small operation. We do not currently hold a SOC 2, ISO 27001, or PCI attestation, and we have not undergone a third-party penetration test. We do not run a paid bug bounty. No system is perfectly secure, and no set of controls can eliminate the risk of a compromise — the measures above reduce it, they do not remove it. If any of this changes, this page changes with it.
8. What you can do
- Use a long, unique password that you do not use anywhere else, stored in a password manager.
- Turn on two-factor authentication and store your recovery codes somewhere offline.
- Start on a paper-trading account until you trust what a strategy does.
- Keep position sizes and per-strategy risk limits set to amounts you can afford to lose — automation executes mistakes as faithfully as it executes good decisions.
- Review your strategy activity and your brokerage statements regularly rather than relying on either system alone.
- Disconnect the brokerage connection when you are not actively using it, and revoke Fuselit from your broker's connected-apps settings if you stop using the Service.
- Be suspicious of any email asking for your password, API keys, or 2FA codes. We will never ask you for them.
9. Reporting a vulnerability
If you believe you have found a security issue, email [email protected] with the subject line "Security" and enough detail to reproduce it — the affected URL or endpoint, the steps you took, and what you observed. We aim to acknowledge reports within three business days and to keep you updated until the issue is resolved.
We will not pursue legal action against researchers who report in good faith and who:
- test only against accounts they own, and never against another user's account or data;
- avoid privacy violations, data destruction, and any degradation of the Service — no denial-of-service, no load or stress testing, no automated scanning that generates significant traffic;
- do not exfiltrate data beyond the minimum needed to demonstrate the issue, and delete it afterwards;
- give us a reasonable opportunity to fix the issue before disclosing it publicly.
We do not offer monetary rewards, but we are glad to credit you once a fix has shipped, if you would like that.
10. If something goes wrong
If we become aware of a breach affecting your personal information or your brokerage credentials, we will notify affected users without undue delay, describe what happened and what data was involved, and tell you what to do — including revoking the brokerage connection and rotating credentials. Where the law requires notification of regulators or a specific timeline, we will follow it.
11. Contact
Security questions, or anything on this page that you would like explained in more detail: [email protected].