Security
The safest thing we can do is hold almost nothing.
Coinmico is a market data platform. It never takes custody of funds, never asks for a private key or a wallet signature, and needs no account to read a price. This page sets out what protects the service that remains, how to report a weakness, and what we do not claim.
Last reviewed 31 August 2026. Reports are acknowledged within two business days.
No custody, ever
There is no deposit, no withdrawal and no wallet connection anywhere on Coinmico. A breach of this site cannot move anyone ’s coins, because this site has never been able to.
Accounts are optional
Prices, charts, screeners and the API need no sign-in. An account exists only to keep a watchlist, a portfolio, alerts and API keys — so the data we could lose about you is small by design.
Blast radius
Five things Coinmico never asks for, and therefore never stores.
Private keys and seed phrases
No feature on the site has a field for one. Anybody asking for yours in our name is impersonating us.
Wallet signatures and approvals
Coinmico never requests a signature or a token approval. Wallet addresses you track are watched read-only, from public chain data.
Custody of funds
No deposits, no withdrawals, no trading. We are not an exchange, a broker or a custodian.
Card and bank details
The site takes no payments, so no card number, IBAN or billing profile exists to be stolen.
Identity documents
There is no KYC on Coinmico. We do not collect passports, selfies or proof of address.
Your trades
A portfolio you enter is a set of numbers you typed, held for your view of them. It is not connected to any exchange account.
What an account does hold is listed in the privacy policy: an email address, a password digest or a Google identifier, and the lists you chose to keep.
How the platform is protected
Controls we run, described precisely enough to be checked.
Security writing is usually vague so that nothing in it can ever be wrong. These are the actual settings; several of them you can verify from your own terminal in a second.
Transport
- HTTPS only over HTTP/2, with certificates renewed automatically.
- HSTS for one year including subdomains, so a browser that has seen the site once refuses to speak plain HTTP to it.
- Cloudflare terminates in front of the origin; www redirects permanently to the apex, the single canonical host.
Browser hardening
- X-Content-Type-Options: nosniff on every response.
- Referrer-Policy: strict-origin-when-cross-origin, so a full URL never leaks to a site you click through to.
- Permissions-Policy denies camera, microphone, geolocation and payment outright.
- Content-Security-Policy pins frame-ancestors to our own origin; only the embeddable widgets are opened for framing.
Passwords and sessions
- Passwords are stored as scrypt digests with a random 16-byte salt each, and compared in constant time.
- A session token is random 256-bit, and the database keeps only its SHA-256 digest — the raw token exists in your cookie and nowhere else.
- The cookie is HttpOnly, Secure and SameSite=Lax, so scripts cannot read it and another site cannot ride it.
- Signing out deletes the session row, not just the cookie. Sessions expire after 30 days.
API keys
- A key is shown once. We store its prefix and a SHA-256 digest, so a copy of our database does not yield working keys.
- Revoking a key stops it on the next request; there is no cached grace period.
- Each key carries an hourly call quota counted at authorisation time, and must travel in an Authorization header — never a query string, where it would leak into logs and referrers.
Abuse and rate limits
- Every route family has a burst budget, an hourly ceiling that catches the patient scraper, and a whole-route brake so a spread of addresses cannot outflank the per-caller rules.
- Sign-in and password routes sit in a deliberately tight tier, counted per address and per account, so credential stuffing costs real time.
- Callers are identified by the address Cloudflare reports; anyone reaching the origin directly is counted by the address they connect from, whatever headers they send.
Servers and network
- SSH accepts keys only — password and keyboard-interactive authentication are disabled on the daemon.
- The firewall allows 22, 80 and 443. Nothing else is reachable from the internet.
- Database, cache and workers talk over a private container network and are never published to a public port.
- Application secrets live in an environment file on the host, readable by root only, and never in the repository.
Backups
- The whole index is dumped nightly and uploaded to object storage in a different provider from the server it protects.
- Fourteen daily copies are kept and older ones are deleted automatically. Each night's upload is confirmed in the backup log; a full restore drill is still outstanding and is listed below.
- Backups hold market data and account records; they are never shared, and access to the bucket is limited to that one job.
Monitoring and recovery
- A health endpoint reports the database, the cache and whether the price index is still moving, and answers 503 when it is not.
- A watchdog checks it every minute and restarts only the component that failed, with a cool-down so a bad minute cannot become a restart storm.
- An external uptime monitor watches the same endpoint from outside our network and alerts us when the box itself is the problem.
Email and identity
- Our domain publishes SPF and DMARC records. DMARC is still in monitoring mode (p=none), so it reports forgery rather than blocking it yet.
- We write from @coinmico.com addresses only, and never send a link asking you to unlock, verify or connect a wallet.
- Google sign-in is verified server-side against Google's own keys, and links to an existing account only when the email matches.
Verify the transport and header claims yourself: curl -sI https://coinmico.com. If a control described here does not match what you observe, that gap is itself a report we want — [email protected].
Coordinated disclosure
Found something? Tell us before you tell the timeline.
Email [email protected] with enough detail to reproduce the issue: the URL or endpoint, the request, what you expected and what happened, and a proof of concept if you have one. Screenshots and a short video help.
We acknowledge within two business days, tell you our assessment and a fix timeline once we have reproduced it, and let you know when it ships. We will credit you by the name you choose unless you would rather stay anonymous.
Safe harbour. Research done in good faith under the rules below is authorised: we will not pursue legal action, and if a third party does, we will say plainly that you were working with us.
We do not pay bounties. Coinmico is a small, self-funded project and has no bug bounty programme; we would rather say so than dangle a reward that never arrives. What we offer is a fast, honest response and public credit.
In scope
- coinmico.com and everything it serves, including the public API under /api.
- Authentication, sessions, account settings, API keys and anything that could expose another user's data.
- Data integrity: a way to make the site publish a price, ranking or supply figure that our own methodology would not produce.
- Server-side request forgery, injection, broken access control, stored or reflected XSS, and cache poisoning.
Out of scope
- Volumetric denial of service, load testing and traffic floods — please do not.
- Reports from an automated scanner with no demonstrated impact, and best-practice findings such as a missing header on a static asset.
- Social engineering of our team or our providers, and physical attacks.
- Vulnerabilities in exchanges, chains, wallets or news publishers we merely read from, and issues in third-party services under their own disclosure policy.
- Self-XSS, clickjacking on pages with no state-changing action, and missing SPF or DMARC on domains that send no mail.
Rules of engagement
Use your own account and test data. Stop at the point you have proven the issue — do not read, alter or keep anyone else ’s data, and do not degrade the service for other visitors. Give us a reasonable window to fix it before you publish; 90 days is a fair default and we will usually be far quicker.
Your side
Keeping your account, and your coins, safe
The realistic attack on a data site is not against our servers — it is someone using our name to reach you. A few habits close that door.
- Check the address bar. We operate coinmico.com and nothing else. A lookalike domain, an “airdrop claim” page or an app store listing in our name is not ours.
- We will never ask you to connect a wallet. No support agent of ours will request a seed phrase, a private key, a signature or a transfer “to verify” anything. Forward anything that does to [email protected].
- Use a password you use nowhere else. Most account takeovers come from a password leaked on another site. A password manager, or Google sign-in, avoids that entirely.
- Treat an API key like a password. Keep it server-side, never in a public repository or a browser bundle, and revoke it the moment it may have leaked — a new one takes seconds.
- Sign out on shared devices. Signing out ends the session on our side too, so a copied cookie stops working.
Where we stop
What we do not claim
A security page that lists only strengths is marketing. These are the gaps we know about today.
- No external audit or certification. Coinmico has not been penetration-tested by a third party and holds no SOC 2, ISO 27001 or smart-contract audit. It has no smart contracts to audit. We will say so here on the day that changes, and not before.
- No two-factor authentication yet. Accounts are protected by a password or Google sign-in; hardware keys and one-time codes are not implemented. Until they are, Google sign-in inherits whatever protection you have on that account and is the stronger option.
- One region, one operator. The service runs on a single server with nightly off-site backups, not a multi-region cluster. A hardware failure means a restore measured in hours, not a silent failover.
- Backups are verified, restores are not yet drilled. Every nightly dump is confirmed uploaded, but we have not yet rebuilt the database from one end to end under timed conditions, so the recovery time above is an estimate rather than a measurement.
- Data can still be wrong. Security is not accuracy. A stream can drop and an indexer can fall behind; what we promise about the numbers themselves is in the disclaimer and the methodology.
Report it and we will fix it.
[email protected] reaches the people who run the servers, not a ticket queue. Acknowledged within two business days.