← Back

Security

Last updated: October 23, 2026

Looking for how GreeksView protects your data instead? That is a separate page: security architecture — what we store, encryption at rest, and exactly what crosses the network.

How to report

Send us enough to reproduce the issue: the affected URL or endpoint, the steps you took, and what you observed. A proof of concept helps. If a report contains sensitive detail, say so and we will arrange another channel.

Please give us a reasonable window to ship a fix before disclosing publicly. We aim to tell you when the fix is live, and we can credit you if you ask us to.

In scope

• Authentication and session handling, including the admin console
• Anything that lets one account read or modify another account's data
• Server-side injection, remote code execution, or SSRF
• Flaws in our broker relay (/proxy/trading) that could expose one user's credentials to another
• Cross-site scripting that survives our escaping
• Broken access control on any /api/ or /admin route

Out of scope

• Findings that require physical or already-authenticated access to a user's own device. Alpaca access tokens from Connect with Alpaca are encrypted in the browser with a non-extractable key and are not stored on our servers, so reading one from an unlocked machine is not a server-side flaw.
• Missing security headers or TLS configuration with no demonstrated impact
• Rate limiting on unauthenticated endpoints, absent a concrete attack
• Automated scanner output without a working proof of concept
• Social engineering of our staff or users, and physical attacks
• Denial of service, volumetric testing, or anything that degrades service for real users

Please do not

• Access, modify, or delete data belonging to anyone but yourself. Register a test account instead.
• Run load or stress tests against production
• Use a finding to place trades, move funds, or read another user's positions

Safe harbor

If you research in good faith and follow this page — you stay within the scope above, respect the list just above, stop and report as soon as you find a vulnerability, and give us a reasonable window before disclosing — we consider your research authorized under this policy, and we will not pursue or support legal action against you for it. If someone else brings a claim over research you did under this policy, we will say that it was authorized. You do not need separate written permission to research under this policy. It does not authorize testing of anyone else's systems, including Alpaca's, which have their own policies. If you are unsure whether something is in scope, ask us first at security@greeksview.com.

What we already do

Some context that may save you time.

• Broker credentials. GreeksView never asks for your broker password or keys. You connect your Alpaca account through Alpaca's own sign-in. Our servers refuse to store broker credentials: the sync endpoint rejects them, and our code does not write them to a database or a log. The security architecture page has the detail.
• Connect with Alpaca. Our server exchanges the authorization code, the one step that needs the app's client secret, then hands the access token to your browser once, without writing it to a database or a log. Between our callback and the app picking it up, it sits in your tab's session storage; from there it is encrypted in your browser under a key that cannot be exported from it. Alpaca market-data requests go from your browser straight to Alpaca. So does the desk's stream of order-status updates. Account, position, order, market-hours, symbol-list and option-contract requests pass through our broker relay, which forwards the token in an Authorization header over TLS for that one request and does not store it or write it to our application logs. The token carries trading scope, so treat it like a password to your account.
• The limits of that encryption. If your browser does not provide WebCrypto or IndexedDB at all, the vault cannot start: the access token is held only in the open page, never written to your browser's storage, and you connect again on each visit. If it provides IndexedDB but refuses to open it, the vault cannot create its key and the token is not saved. The vault protects stored data. It does not protect against a script running inside the page, which is why cross-site scripting is in scope above.
• Sessions and passwords. Session cookies are httpOnly and, in production, carry the __Host- prefix. Sessions expire after a period of inactivity. Passwords are hashed with bcrypt, and email tokens are stored only as SHA-256 hashes. An account is locked after 10 failed sign-ins in a row and stays locked for 15 minutes after the 10th failure. Once a lock lifts, one more failed sign-in locks it again. While an account is locked, the correct password still signs in from a browser that has signed in to that account before, and a password reset clears the lock. Reader accounts do not have two-factor authentication.
• Transport. The hosted site sends a Strict-Transport-Security header with a maximum age of one year that includes subdomains.
• The admin console has its own sign-in and cookie, separate from reader accounts. Two-factor authentication is enforced for every admin account that has an authenticator enrolled. Console sessions are server-side records that we can revoke: a session ends after 15 minutes without activity and at most two hours after sign-in. The admin audit trail is insert-only for the application's database role once the database grants from our deployment script are applied.

No bounty

We are a small independent product and do not run a paid bug-bounty programme. If you would like credit for a valid report, tell us in your email and we will credit you by name or handle once the fix is live. There is no acknowledgements list yet.

Contact

security@greeksview.com · machine-readable version at /.well-known/security.txt

Fathomline Analytics LLC · 4601 E. Douglas Ave., Ste 150, Wichita, KS 67218

See also: Terms · Privacy Policy · Options Risk Disclosure