Docs·Web App·Security

Security — overview

How mrD-Indicators is designed so that installing the app — in a browser tab or as a PWA on your home screen — cannot read your crypto wallet, drain your exchange, or exfiltrate keys. The threat model, the technical guarantees, and the proof you can verify yourself.

Traders ask one question more than any other when they see an "Install App" prompt:

"If I install this on my phone / laptop, can it read my wallet? Steal my seed phrase? Drain my Binance account one day when I'm not looking?"

Short answer: no, and the reasons are mechanical, not promises. mrD-Indicators is a web app. Even installed to your home screen as a PWA, it runs inside the browser sandbox — the same sandbox that stops every random website you open from reading your MetaMask, your Ledger Live, or your clipboard. We did not invent that boundary; the browser enforces it for every site on the internet, and we get the same restrictions everyone else gets.

What we did do is document the boundary, publish the proof, and design the trade flow so that even a leaked API key cannot move your funds. This page is the entry point to that story. The next three pages give you the verification details — read them in order if you want to audit, skip them if you trust the summary.

The threat model — what users actually fear

Pinned from real questions in our Telegram support channel:

Lo ngại (concern)Where the answer lives
"PWA cài vào máy nên đọc được ví MetaMask / Phantom / Rabby."What a PWA cannot do — origin isolation rules apply to every site, ours included.
"PWA đọc được file ví desktop (Ledger Live, Exodus, …)."What a PWA cannot do — browsers cannot read your filesystem without an explicit file picker.
"PWA lurk clipboard, đọc seed phrase khi paste."What a PWA cannot do — clipboard reads require user gesture + permission prompt. No background lurking.
"PWA gửi keystroke về server, lấy mật khẩu sàn."What a PWA cannot do — keystrokes outside our own input boxes are not observable by JavaScript.
"Một ngày đẹp trời, app tự update mã độc rồi rút sạch."Verify the app — every release publishes a SHA-256 manifest of the bundle our CDN serves + a Sigstore signature, to our public release repo at github.com/PhamNhinh/mrd-indicators-releases. The same signature is recorded in the public Sigstore Rekor transparency log. You can prove the bundle in your browser matches the one we publicly attested — and the manifest itself was signed by GitHub Actions inside our CI, not uploaded manually by anyone.
"Lỡ key Binance bị leak thì sao?"API key permissions — we require withdraw-OFF + IP-whitelisted keys. A leaked key cannot withdraw, cannot transfer, cannot be used from any other machine.

If your fear isn't on the list, open a ticket — we'll answer it on this page so the next person can read the answer too.

The four layers of defence

mrD-Indicators is not one feature that protects you — it's four overlapping layers. Any one of them defeats the "drain my wallet" attack on its own; together they make the failure modes vanishingly rare.

Layer 1 — Browser sandbox (we don't write this; the browser enforces it)

A web page cannot read your filesystem, cannot read other browser extensions' storage, cannot read your clipboard in the background, cannot record your keystrokes outside its own inputs, and cannot install itself onto your machine outside the PWA install flow you explicitly accept. This is not a promise we make — it is the security model Chrome, Safari, Firefox, and Edge all enforce on every website on the internet, including ours. See What a PWA cannot do for the technical details and the MDN references you can verify yourself.

Layer 2 — Strict Content Security Policy (we do write this)

We ship a Content Security Policy header that whitelists exactly which domains the app is allowed to connect to: our own servers, the exchanges we trade against, our notification service, our analytics. Anything else — including a hypothetical malicious script that somehow got into our bundle — would be blocked by your browser before a single network request leaves your machine. You can open DevTools → Network and see for yourself: every connection the app makes is on a small, named list. See Verify the build for the live policy and how to read it.

Layer 3 — Verifiable bundle attestation via a public release repository (we do write this)

Our source repository is private (we are a commercial product, not an open-source library) — but the bundle that ships into your browser is independently verifiable. A GitHub Actions workflow runs on a regular cadence (and on every release tag), fetches the live bundle from https://app.mrd-indicators.com the same way your browser would, hashes every file, signs the manifest, and publishes the result to a separate, public GitHub repository:

That repository contains only hashes, signatures, and release notes — never source code. The signatures are also recorded in Rekor, a public, append-only transparency log run by the Open Source Security Foundation, so the verification chain has two independent surfaces. Anyone — you, your security-conscious friend, a third-party audit firm — can download manifest.sha256.txt + app.sigstore.jsonl from a release page, hash the bundle their browser is running, and run one shell command (cosign verify-blob) to prove that:

  • The bundle in their browser matches the one our CI fetched from the CDN.
  • The manifest was signed by GitHub Actions inside our CI — not uploaded manually by anyone.
  • The signing identity is recorded in a transparency log we cannot rewind.

No "we'll just push this hotfix tonight" with no audit trail, no possibility of a rogue engineer swapping a different bundle onto the CDN without it being detectable on the next CI snapshot. See Verify the app.

Layer 4 — Trade-only API keys with no withdrawal (we enforce this)

Even if the rest of the stack failed — if the bundle were tampered with, the CSP bypassed, the sandbox broken — the worst case still cannot move your funds. Our exchange-connect flow refuses any API key with Enable Withdrawals turned on. We strongly recommend you also IP-whitelist the key to our server IPs, so even a leaked key + secret cannot be used from any other machine. See API key permissions.

What we don't have access to

For completeness, the list of things we never see, even on our backend:

  • Your exchange password.
  • Your exchange 2FA codes.
  • Your withdrawal whitelist.
  • Your private keys (we don't custody funds — see API Connect overview).
  • Your seed phrase. (We have no surface anywhere that asks for one. If anyone claiming to be us asks for a seed phrase, it is a scam — report it to support immediately.)
  • Your other browser extensions, your other tabs, your other files.

How a determined attacker would actually attack you

Useful framing: the realistic threats to a crypto trader do not look like "install a PWA, app reads wallet". They look like:

  1. Phishing — a Telegram message linking to app.mrd-1ndicators.com (one character off) that asks you to paste your API key. The fake site can then use the key — but if the key is trade-only + IP-whitelisted, the attacker still can't withdraw. Always check the URL bar.
  2. Browser-extension malware — a "free RSI bot" extension you installed that quietly reads every page you open. This is the real risk vector; review your extensions periodically.
  3. Compromised OS — a malicious app you installed from outside the App Store / Play Store. Once root, all bets are off — but installing our PWA does not put us in that category. PWAs run in the browser sandbox.
  4. SIM-swap / account-takeover — attacker convinces your phone carrier to port your number, then resets your exchange password. Hardware-key 2FA defeats this; SMS 2FA does not.

None of these are easier because you have our PWA installed. None of them are harder if you don't.

What's next